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ABSTRACT 


Airborne  Mine  Countermeasures  (AMCM)  Command  Control  Commimication 
Computer  and  Intelligence  (C''I)  baseline  currently  consists  of  stand-alone  tactical 
decision  aids.  Information  such  as  aircraft  position,  equipment  status,  and  abbreviated 
mine-like  contact  reports  cannot  be  transferred  in  any  form  other  than  voice  from/to  the 
MH-53E  helicopters  while  conducting  Airborne  Mine  Countermeasures  operations. 

There  are  currently  no  methods  to  transfer  sonar  video  or  single-frame  imagery  of  mine¬ 
like  objects  between  any  Mine  Warfare  (MIW)  imits  in  a  near-real-time  maimer.  Delays 
lasting  several  hours  are  frequently  encountered  before  the  results  of  a  "rapid 
reconnaissance"  airborne  minehunting  mission  are  made  available  to  the  rest  of  the 
fleet  and/or  MIW  community.  In  order  to  improve  command  and  control,  the 
AMCM  Mine  Warfare  community  must  integrate  all  of  its  C'^I  assets  onto  a  tactical 
internet. 

This  thesis  presents  a  tactical  internet  for  AMCM  with  an  open,  standards- 
based  modular  architecture.  It  is  based  on  the  TCP/IP  network  model  using 
common  protocols  and  interfaces.  Command  and  control  will  significantly 
improve  as  this  network  will  provide  a  methodology  to  transfer  critical  information 
between  AMCM  C'*!  assets  and  tactical  networks  world-wide.  Results  from  a 
comprehensive  laboratory  prototype  demonstration  using  commercial  off-the-shelf 
(COTS)  equipment  are  presented  along  with  lessons  learned.  Laboratory  results 
show  that  this  system  works  and  can  be  deployed  for  testing  at  sea. 
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I.  INTRODUCTION 


A.  OVERVIEW 

The  Helicopter  Mine  Countermeasures  Squadron  (HM)  Commander 
currently  has  no  method  to  automatically  monitor  airborne  mine  countermeasures 
(AMCM)  mission  performance,  track  aircraft  position,  or  to  relay  time-critical 
information  between  the  AMCM  MH-53E  helicopter  assets  and  the  HM 
Squadron's  Mobile  Operations  Center  (MOC).  Often  there  is  a  two-to-four  hour 
delay  before  any  information  from  post-mission  analysis  (PMA)  is  forwarded  from 
the  HM  Squadron's  MOC  to  the  MCM  Commander  via  standardized  message 
formats.  This  delay  is  tactically  unacceptable  as  it  undermines  the  basic  premise 
of  using  AMCM  assets  for  rapid  reconnaissance  in  that  it  is  not  rapid. 

As  a  result  of  this  lack  of  capability,  operational  command  and  control  is 
not  optimized  and  rests  on  voice  communications  for  data  transfer.  Non¬ 
development-item  (NDI)  and  commercial-off-the-shelf  (COTS)  equipment  and 
software  is  available  today  which,  when  coupled  in  a  coherent  architecture  with 
existing  MH-53E  AMCM  systems,  can: 

•  Automatically  monitor  mission  performance 

•  Provide  flight  following  and  track  AMCM  asset  positions 

•  Be  used  to  report  mine-like  contact  locations 

•  Process  real-time  full-motion  sonar  video,  and 

•  Provide  near-real  time  single  frame  sonar  imagery. 
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This  system  provides  near-real  time  mission  analysis,  improves  command 
and  control,  and  the  enhances  the  overall  effectiveness  of  the  AMCM  assets.  Thus 
a  great  improvement  in  MH-53E  AMCM  capabilities  is  technically  feasible. 

B.  PURPOSE  OF  RESEARCH 

The  purpose  of  this  thesis  is  to  identify  an  AMCM  Cl  Information  System 
architecture  which  will  provide  complete  connectivity  between  all  airborne  and 
ship  and/or  shore  based  AMCM  C'^I  assets.  This  system  will  lay  an  interoper¬ 
ability  foundation  -  both  within  the  MIW  community,  and  externally,  with  the 
Navy  and  other  Joint  components.  High  levels  of  availability,  scalability, 
compatibility,  and  flexibility  will  be  achieved  as  a  result  of  the  information 
system’s  network  based  architecture.  The  design  limits  risk  and  complexity  by 
using  open  standards  as  common  interfaces  between  modular  system  components, 
regardless  of  whether  those  components  are  development  items  or  not,  and  thus 
provides  an  evolvable  baseline. 

This  thesis  will  outline  the  technical  feasibility  of  a  internetworked  Internet 
Protocol  (IP)  compatible  AMCM  C^I  Information  System  using  commercial-off- 
the-shelf  (COTS)  and  non-development  item  (NDI)  equipment  available  today. 
This  thesis  also  reports  initial  proof-of-concept  testing  over  radio  frequency  (RF) 
environments.  Numerous  configuration  options  are  available  as  the  individual 
components  within  the  system  can  be  interchanged  easily  within  the  modular 
architecture.  The  AMCM  C'*!  Information  System  outlined  in  this  thesis  is  capable 
of  automatically  monitoring  the  performance  of  AMCM  assets,  transferring  mine¬ 
like  object  position  information,  and  providing  real-time  sonar  video  and  mine-like 
object  imagery  from  Navy  MH-53E  helicopters  to  the  MOC  in  ranges  up  to  and 
including  over-the-horizon.  The  system  will  enable  real-time  computer-aided 
mine-like  object  detection  and  eliminate  unnecessary  delays  in  processing  critical 
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time-sensitive  information.  This  system  also  provides  avenues  for  further  addition 
of  automatic  target  recognition  processes  to  the  airborne  sensor.  In  summary,  the 
purpose  of  the  AMCM  Information  System  is  to  provide  complete  connectivity 
between  airborne  and  ship/shore  based  AMCM  C'^I  assets. 

C.  SCOPE  OF  RESEARCH 

This  research  presents  the  requirements,  architectural  design,  initial 
integration  and  a  proof-of-concept  demonstration  of  an  experimental  prototype 
AMCM  C'*!  Information  System.  A  laboratory  demonstration  shows  the 
conceptual  as  well  as  technical  viability  of  the  concepts  presented  within  this 
paper.  The  initial  proof-of-concept  demonstration  sets  the  stage  for  further  testing 
and  evaluation  of  the  airborne  operational  data  link  design  that  is  presented  in  this 
thesis.  This  thesis  examines  the  following  research  questions: 

1.  What  are  the  requirements  of  an  AMCM  C‘*I  Information  System? 

2.  What  is  the  appropriate  system  architecture  for  the  AMCM  C'*! 
Information  System? 

3.  How  can  the  AMCM  C'*!  Information  System  be  used  effectively 
during  AMCM  operations? 

4.  What  are  some  effective  systems  engineering  tradeoffs  between 
existing  technology  and  operational  requirements? 

5.  How  can  the  AMCM  C"!  Information  System  be  used  to  transfer 
video/imagery  data? 

6.  How  will  technology  currently  under  development  impact  AMCM 
C'^I  Information  System? 

7.  Is  it  possible  to  demonstrate  a  simple  working  prototype? 

This  thesis  provides  answers  to  all  of  these  questions. 
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D.  LIMITATIONS 


All  of  the  equipment  used  for  the  proof-of-concept  demonstration  was 
loaned  by  vendors.  As  a  result,  some  of  the  equipment  is  not  exactly  the  same  as 
the  equipment  which  is  specified  for  use  in  the  final  airborne  configuration. 
Further,  the  lab  experience  shows  that  some  equipment  is  mismodularized  and  has 
the  wrong  interfaces.  Specifically,  these  interfaces  are  limited  to  serial  connec¬ 
tions  only  since  the  desired  local-area  network  (LAN)  interfaces  were  not 
provided.  As  a  result,  several  different  kinds  of  serial-to-LAN  connections  had  to 
be  used.  However,  the  overall  architecture  remains  consistent  as  both  versions 
comply  with  the  architectural  standards  described  within  this  thesis.  Additionally 
the  sonar  imagery  from  the  sensor  itself  is  simulated  by  using  a  VHS  video 
cassette  tape  of  sonar  sensor  data  as  the  input  data  source. 

Finally,  the  unexpected  termination  of  orders  and  equipment  to  complete 
this  project  precluded  a  fully  planned  end-to-end  demonstration  test  at  sea  using 
MH-53E  assets.  This  unfortunate  decision  has  precluded  rapid  testing  and  deploy¬ 
ment  of  a  working  system  to  fleet  mine-hunting  helicopters  that  lack  the  connec¬ 
tivity  needed  to  properly  perform  their  assigned  mission. 

Round-the-clock  effort  was  able  to  record  the  knowledge  gained  in  this 
thesis  in  the  two  weeks  permitted  between  change  of  orders  and  graduation.  The 
author  and  advisors  remain  optimistic  that  these  setbacks  are  temporary  and  the 
solutions  provided  in  this  thesis  may  yet  be  reimplemented.  Fleet  need  for  such 
solutions  is  clearly  critical. 

E.  THESIS  ORGANIZATION 

The  thesis  is  organized  as  follows:  Chapter  II  defines  the  problem  state¬ 
ment.  Chapter  III  describes  AMCM  C*!  Information  System  Architecture,  which 
provides  the  big  picture  of  the  overall  solution.  Chapter  IV  presents  the  AMCM 
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Tactical  Internet.  Chapter  V  describes  the  common  networking  interfaces. 
Chapter  VI  describes  the  requirements  perspective  and  outlines  the  systems 
engineering  trade-offs  necessary  to  achieve  near-real  time  results.  Chapter  VTI 
discusses  the  related  work  and  the  current  relationship  with  the  AMCM  C'^I 
Information  System.  Chapter  VIII  presents  the  recommendations  for  future  work. 
Chapter  IX  presents  the  demonstration  results.  Chapter  X  presents  the  lessons 
learned  and  conclusions. 
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11.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

This  chapter  defines  the  AMCM  MH-53E  command  and  control  problem 
and  provides  a  baseline  assessment  of  current  AMCM  C'^I  systems. 

B.  COMMAND  AND  CONTROL  PROBLEM 

The  ability  to  make  sound  and  timely  decisions  is  the  key  objective  of  the 
command  and  control  process. 

The  defining  features  of  command  and  control  problem  -  uncertainty 
and  time  -  exert  a  significant  influence  on  decision  making.  As 
knowledge  about  a  situation  increases,  our  ability  to  make  an  appro¬ 
priate  decision  also  increases.  [Ref.  1  :p.  24] 

In  amphibious,  expeditionary,  and  littoral  warfare  operations,  the  mine 
warfare  tactical  picture  is  a  critieal  component  of  the  overall  tactical  picture.  Each 
group  commander  needs  an  accurate  and  timely  view  of  where  he  can  and  cannot 
safely  sail.  The  AMCM  component  of  the  MIW  forces  is  a  critical  component  to 
this  tactical  picture. 

Proper  command  and  control  improves  a  commander’s  situational  aware¬ 
ness.  Proper  command  and  control  enables  the  commander  to  understand  a 
situation,  select  a  course  of  action,  issue  directives,  monitor  on-going  operations 
and  effectively  evaluate  the  results.  Proper  command  and  control  also  maximizes 
search  effectiveness  and  minimizes  the  risks  of  mine  detonation  against  friendly 
shipping. 
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1.  MIW  Community 

Command  and  Control  is  significantly  impaired  in  the  MIW  community  due 
to  the  lack  of  a  community-wide,  fully  integrated  C^I  system  that  is  also  fully 
interoperable  with  the  larger  group  commander’s  C'^I  system.  Communications 
coimectivity  must  extend  to  the  individual  asset  level  for  Mine  Warfare  (MIW) 
command  and  control  to  be  optimized.  For  example,  information  such  as  asset 
position,  status,  etc.  is  essential  to  enable  timely  and  tactically  efficient  deconflie- 
tion  between  MIW  assets. 

2.  AMCM  Community 

The  MIW  command  and  control  problem  is  aggravated  by  the  AMCM 
community's  lack  of  a  cohesive,  interoperable  C"!  system.  AMCM  surveillance 
"minehunting"  missions  have  a  high  percentage  of  mission  time  dedicated  to 
searching.  Invariably  multiple  units  are  involved  in  each  operation.  However,  the 
AMCM  assets  used  in  mine-hunting  and  the  surface/EOD  based  assets  used  to 
disable/destroy  the  mine  have  no  means  to  transfer  information  other  than  voice. 
Therefore  a  considerable  amount  of  time  passes  between  initial  detection  and 
actual  notification  of  prosecution  asset,  since  multiple  information  hand-offs  are 
required.  These  hand-offs  are  further  delayed  by  the  time  it  takes  to  complete  the 
mission  (after  spotting  the  contact  on  the  sonar  video),  helicopter  transit  time  from 
the  operating  area  to  the  base,  transfer  of  the  sonar  tape  from  the  helicopter  to  the 
MOC,  review  of  tape  during  post-mission  analysis,  drafting  the  message  to  pass 
the  information,  and  finally  the  time  it  takes  to  transfer  the  message  to  the 
prosecuting  asset  itself. 

Therefore,  these  delays  are  extensive  and  operationally  significant  since  the 
AMCM  Commander  does  not  have  an  effective  and  efficient  means  to  share 
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critical  time-sensitive  MIW  information  with  MCM,  SMCM,  MHC,  and  EOD 
commanders. 

C.  BASELINE  CAPABILITIES 

The  AMCM  community’s  O'*!  baseline  currently  consists  of  stand-alone 
tactical  decision  aids  (TDA)  such  as  the  Mission  Planning  System  (MPS)  and  the 
Post-Mission  Analysis  (PMA)  Workstation.  Also,  Mine  Warfare  Environmental 
Decision  Aids  Library  (MEDAL),  the  mine  warfare  segment  to  the  Joint  Maritime 
Command  Information  System  (JMCIS),  has  not  yet  been  integrated  with  the  MH- 
53E  AMCM  aircraft  to  provide  position  location  information  (PLI)  or  mission 
status  information  from  the  AMCM  helicopter  sensors.  Information  such  as 
position,  equipment  status,  and  abbreviated  mine-like  contact  reports  currently 
cannot  be  transferred  in  any  form  other  than  voice  to  or  from  the  airborne  MCM 
helicopters  while  conducting  AMCM  operations.  Voice  transfers  of  data  are  not 
preferred  as  they  are  manpower  intensive  and  error-prone  in  high-stress  environ¬ 
ments. 

There  is  currently  no  method  to  transfer  sonar  video  or  single  frame 
imagery  of  mine-like  objects  between  units  in  a  real-time  manner.  Figure  2.1 
shows  the  current  C'*!  communications  baseline.  The  digital  sonar  data  is  instead 
converted  to  video  and  stored  on  magnetic  digital  tapes  during  AMCM  mine¬ 
hunting  operations.  Sonar  operators  mark  contacts  with  a  joy  stick  by  pressing  a 
button  as  the  contacts  appear  on  a  waterfall  type  display  screen.  The  tapes  are 
removed  from  the  aircraft  upon  landing  and  are  reviewed.  The  marks  are  reviewed 
and  a  decision  is  made  whether  the  mine-like  contact  is  valid  and  should  be 
reported  to  the  Mine  Counter-measures  Group,  which  includes  the  MCM 
Commander,  the  EOD  divers,  SMCM  assets  etc.,  or  be  dismissed  as  a  non-mine- 
like  object.  This  process  requires  several  hours  to  complete  following  each 
mission. 
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Figure  2.1.  Existing  Baseline  for  Minesweeping  Helicopter  Connectivity 
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D.  BASELINE  NAVAL  C"I  SYSTEM 


Naval  C*!  systems  are  "the  information  systems,  equipment,  software,  and 
infrastructure  that  enable  the  commander  to  exercise  authority  and  direction  over 
assigned  forces."  [Ref  l:p.  24] 

Cl  systems  need  to  facilitate  information  flow  throughout  the  force,  not 
just  up  and  down  the  chain  of  command.  They  need  to  be  designed  from  the 
ground  up  to  be  part  of  an  architecture  that  can  be  easily  integrated  with  other 
operational  systems,  software,  and  databases.  O'*!  systems  support  the  four  basic 
functions:  [Ref  1] 

•  Collecting.  The  gathering  and  formatting  of  data  for  processing. 

•  Processing.  Filtering,  correlating,  fusing,  evaluating,  and  the 
displaying  of  data  to  provide  overview  of  situation. 

•  Distributing.  Forwarding  execution  or  background  information  to 
appropriate  locations  for  further  analysis  or  use. 

•  Protecting.  Safeguarding  the  information  from  attempts  to  exploit, 
destroy  or  corrupt  it. 

E.  FOCUS  FOR  SYSTEM  DESIGN 

The  AMCM  C^I  assets  must  be  integrated  and  internetworked  so  that  they 
can  be  effectively  used  together.  Once  assets  are  properly  integrated  onto  a  local- 
area  network  (LAN),  with  an  overall  goal  of  complete  connectivity  with  other 
MCM  MIW  £issets,  then  optimal  C^I  integration  can  be  achieved.  The  focus  must 
be  on  building  a  communications  network  that  interconnects  the  AMCM  C^I  assets 
into  a  cohesive  system,  which  includes  both  the  MOC  and  any  airborne  MH-53E. 


The  system  must  use  standard  data  element  definitions  so  that  it  is  widely 
compatible  and  not  limited  to  any  specific  decision  support  system  or  sensor. 

F.  SUMMARY 

The  AMCM  community  needs  to  fully  integrate  the  AMCM  Helicopter 
Squadron’s  C'*!  assets.  This  can  be  realized  through  the  development  of  an 
integrated  Internetworked  AMCM  C'*I  Information  System.  A  great  opportunity 
currently  exists  in  the  AMCM  community  to  take  advantage  of  a  clean  slate  in 
forming  a  real-time  AMCM  C'^I  Information  System.  Architecturally,  there  are 
virtually  no  legacy  systems  to  incorporate  as  minimal  compatibility  currently 
exists  between  AMCM  C'^I  programs  such  as  MEDAL/JMCIS  and  other  programs 
such  as  the  Mission  Planning  System  (MPS).  As  a  result,  there  are  no  systems 
which  require  monumental  reconfiguration  efforts  in  order  to  achieve  compati¬ 
bility.  Previous  attempts  at  solving  the  C'*!  problems  facing  AMCM  have  always 
resulted  in  the  concentration  of  efforts  toward  developing  a  data  link  to  send 
information  back  from  the  helicopter  to  the  MOC.  Often  data  links  are  designed 
that  are  sensor/hardware  specific  and  cannot  be  used  with  other  sensors  or  mission 
systems  (stovepipes).  They  are  costly  and  difficult  to  upgrade  as  they  are  mission 
specific  and  tend  to  use  proprietary  hardware/software  configurations.  Inevitably, 
the  wrong  focus  has  yielded  the  wrong  solution. 

The  Airborne  Mine  Countermeasures  (AMCM)  community  needs  a 
communications  network  that  interconnects  the  AMCM  C^I  assets  into  a  cohesive 
network,  independent  of  what  is  to  be  carried  over  it.  Once  connected,  data  can  be 
transported  via  any  method  and  received  at  the  other  end  as  long  as  it  is  in  a  format 
that  is  compatible. 
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III.  SYSTEMS  ARCHITECTURE 


A.  INTRODUCTION 

This  chapter  presents  the  Internetworked  AMCM  C^I  Information  System 
architectural  model.  It  explains  the  design  concepts  of  the  internetworked  AMCM 
C'^I  Information  System  architecture. 

B.  AMCM  C^I  ARCHITECTURE 

The  Internetworked  AMCM  C"*!  Information  System  architecture  is  based 
on  a  network-centric  design  that  is  inherently  modular  and  allows  the  exploitation 
of  open  standards  and  common  interfaces.  By  dividing  the  problem  into  two  parts 
(the  network  and  modular  end  systems)  the  issues  can  be  broken  down  between; 

1 .  What  is  the  proper  network? 

2.  What  is  the  proper  design,  specification,  and  configuration  of  the 
modular  end-systems  that  are  to  be  attached  to  the  network? 

The  AMCM  C'*!  Information  System  presented  in  this  thesis  is  composed  of 
multiple  mobile  local-area  networks  (LAN)  interconnected  via  a  radio-based 
wide-area  network  (WAN).  The  MH-53E  helicopter  is  first  equipped  with  a 
mobile  LAN  designed  to  fit  onto  a  removable  pallet.  The  MOC  must  also  be  fitted 
with  a  LAN.  The  MH-53E  and  MOC  LANs  are  then  interconnected  via  a  radio 
WAN.  Within  the  modular  design  of  the  network,  open  standards  and  common 
interfaces  will  be  used  to  ensure  performance  and  interoperability  between  the 
component  parts  on  each  of  the  LANs. 
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1.  Network-Centric 

The  tactical  internet  is  obviously  the  central  focus  of  a  network-centric 
system  design.  The  overall  system  is  composed  of  sensors  and  processors  attached 
to  the  network  as  shown  in  Figure  3.1.  The  network-centric  approach  avoids  the 
temptation  to  build  the  system  around  any  central  component  -  where  failure  or 
obsolescence  would  require  replacing  the  entire  system.  Instead,  the  network  itself 
is  used  to  eliminate  bottlenecks,  single  points  of  failure,  and  serial  connectivity. 

2.  Modular 

The  AMCM  C^I  Information  System  has  a  modular  design.  The  system  can 
be  divided  into  sensors,  processors  and  communications  modules  that  are  attached 
through  open  interfaces  to  the  network.  Modular  architectures  are  flexible, 
scalable,  reliable  and  have  improved  performance. 

3.  Common  Interfaces 

The  are  numerous  ways  to  interconnect  the  end  systems  on  a  network. 
Interfaces  are  needed  to  physically  connect  end-systems  to  the  network.  Protocols 
are  required  to  provide  integrated  services  and  to  manage  components.  Data  must 
be  defined  and  packaged  so  that  it  may  delivered  and  subsequently  unpackaged  in 
a  way  it  can  be  used  effectively.  Common  interfaces  are  required  to  ensure 
compatibility  between  end  systems  so  that  the  data  can  be  wrapped,  sent  over  the 
network,  received, 
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Figure  3.1.  Network-Centric  Approach  to  Multiplatform  Conuectivity 
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unwrapped  and  then  used  in  a  satisfactory  manner  over  and  over  again,  all  over  a 
tactical  internet.  These  common  interfaces  are  shown  in  Figure  3.2. 


Common  Interface: 

Standard  Type: 

Common  Data  Definition 

Data  Standard 

Local- Area  Network  (LAN)  Hardware 
Interface 

Network  Standard 

Transmission  Control  Protocol  /  Internet 
Protocol  (TCP/IP) 

Network  Standard 

Electronic  Mail  (E-Mail)  Envelope 
Definition 

Network  Standard 

Simple  Network  Management  Protocol 
(SNMP)  Agents. 

Network  Standard 

Figure  3.2.  Common  Interfaces  for  Network-Centric  Approach 


C.  OPEN  STANDARDS 

The  AMCM  C'*!  Architecture  proposed  in  this  thesis  uses  open  standards. 
Open  standards  are  publicly  documented.  As  a  result,  they  are  nonproprietaiy  and 
supported  by  numerous  vendors.  Open  standards  promote  interoperability  between 
products  made  by  other  vendors.  Open  standards  also  promote  competition,  which 
reduces  costs  and  improves  product  quality  as  vendors  compete  among  each  other. 
Finally,  open  standards  encourage  growth  as  components  can  be  readily  added 
which  are  compatible  with  the  current  system  regardless  of  the  original  vendor  or 
contractual  source. 

D.  SUMMARY 

The  AMCM  O'*!  systems  architecture  has  a  network  centric  modular  design 
that  uses  common  interfaces  and  open  standards.  Other  attempted  solutions  that 
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connect  proprietary  non-networked  systems  in  serial  will  continue  to  fail.  A 
networked  approach  can  connect  all  platforms  and  equipment  in  the  AMCM 
system. 
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IV.  AMCM  TACTICAL  INTERNET 


A.  INTRODUCTION 

A  tactical  network  provides  connectivity  between  the  modular  sensors, 
processors,  and  decision  support  equipment.  The  AMCM  Information  System 
proposed  here  consists  of  a  local-area  network  (LAN)  in  each  of  the  MH-53E 
helicopters,  LAN  in  MOC  and  radio-wide-area  network  (WAN)  to  interconnect 
MH-53E-LAN  to  MOC-LAN.  The  interconnection  of  these  LAN  groups  forms  an 
internetwork,  or  what  is  more  commonly  referred  to  as  an  internet.  Such  a 
localized  internet  is  not  connected  to  the  global  Internet. 

B.  ROUTER  BASED 

The  AMCM  Tactical  Internet  is  a  classical  router-based  internet  as  shown  is 
Figure  4.1 .  The  AMCM  router-based  network  will  consist  mainly  of  point-to- 
point  connections  between  the  MH-53E  LANs  and  the  MOC  LAN.  The  radio 
communications/cryptological  equipment  is  attached  to  the  network  via  the 
routers.  Routers  are  devices  that  interconnect  networks  that  are  either  WAN  or 
LAN.  Routers  provide  intercommunications  between  networks  with  multiple 
protocols.  [Ref  2]  The  router  examines  the  network  address  of  each  packet.  It 
checks  the  address  against  its  internal  tables  and  determines  the  best  way  to  send 
the  packet  to  the  next  router  or  destination  network.  Those  packets  that  contain  a 
network  address  different  from  the  originating  processor’s  address  are  forwarded 
or  "routed"  to  that  network.  Routers  also  have  network  management,  compression, 
and  filtering  capabilities.  Routers  can  be  used  to  maintain  direct  control  of  the 
path  the  packet  takes  from  sender  to  receiver. 


19 


MH-53E  LAN 


ROUTER 


RADIO  WAN 


ROUTER 


Figure  4.1.  Tactical  Internet  Topology 
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C.  MH-53E  HELICOPTER  LAN 


Internally,  the  MH-53E  helicopter  LAN  uses  an  Ethernet  (IEEE802.3), 
which  is  a  carrier  sense  multiple  access/collision  detection  (CSMA/CD)  lOBase-T 
network  which  provides  10  Mbps  throughput  at  the  physical  layer.  An  Ethernet 
hub  is  used  to  interconnect  the  end  systems  and  the  router  as  shown  in  Figure  4.2. 
Scalability  is  inherent  as  numerous  Ethernet  hubs  can  be  attached  to  each  other. 
The  MH-53E  LAN  components  will  also  host  a  management  agent  software 
program  to  communicate  with  a  central  management  station.  The  MH-53E  LAN 
router/hub  components  can  be  mounted  on  a  palletized  rack.  Therefore  the  LAN  is 
portable  and  can  be  removed  as  required. 

D.  MOBILE  OPERATIONS  CENTER  (MOC)  LAN 

The  MOC  LAN  uses  an  Fiber  Data  Distributed  Interchange  (FDDI)  back¬ 
bone  which  provides  100  Mbps  throughput.  Two  or  more  FDDI/  Ethernet  hubs  are 
attached  to  the  backbone  to  provide  the  routers  and  end  systems  with  easy  access 
to  the  network  as  shown  in  Figure  4.3.  To  ensure  the  highest  levels  of  avail¬ 
ability,  installation  of  a  dual  fiber-optic  ring  network,  with  dual-attach  station 
(DAS)  and  duplicate  sets  of  router/radio  frequency  communication  equipment  are 
recommended.  The  dual  fiber  counter-rotating  rings  allow  network  self-healing 
after  cable  or  equipment  malfunctions.  DAS  is  the  attachment  of  critical  equip¬ 
ment  via  two  independent  connections  to  the  network.  Duplicate  router/commun¬ 
ication  equipment  is  recommended  to  provide  redundant  communications  paths  in 
the  event  of  a  single  system  failure.  The  MOC  LAN  will  also  host  the  Network 
Management  Station.  Each  of  the  remote  LANs  will  have  management  agents  that 
will  be  polled  and  controlled  by  the  management  station  in  the  MOC. 
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Figure  4.2.  Proposed  MH-53E  LAN 
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E.  RADIO-BASED  WAN 


The  wireless  radio-based  WAN  environment  requires  different  design  and 
protoeol  considerations  over  the  standard  "wired"  LANs  internal  to  the  MH-53E 
and  MOC.  Although  network  protocols  do  not  care  whether  fiber,  copper,  or 
wireless  physical  media  is  used  to  pass  information,  most  network  protocols  are 
specifically  designed  for  optimal  use  over  wired  networks.  To  ignore  the  unique 
characteristics  of  wireless  mobile  transmissions  can  lead  to  the  development  of  a 
network  with  terrible  performance  even  though  it  is  logically  correct.  At  this  time 
there  are  no  widely  accepted,  reliable,  multicast  transport  layer  protocols  that  can 
be  implemented  over  a  wireless  radio-based  WAN.  In  order  to  avoid  the 
implementation  of  a  wireless  networking  catastrophe,  which  might  have  resulted 
from  using  standard  cabled  network  design  and  protocols,  the  AMCM  radio-based 
WAN  is  treated  as  a  point-to-point  transmission  channel  until  the  protocol 
standards  for  true  radio-based  WANs  are  widely  implemented.  This  approach  is 
reliable  and  well  understood. 

1.  Interim  Solution 

As  an  interim  solution,  point-to-point  AX.25  packet  radio-based  coimec- 
tions  are  used  to  interconnect  the  MH-53E  LANs  to  the  MOC  LAN  as  shown  in 
Figure  4.4.  AX.25  is  a  data  link  layer  protocol  that  is  the  de  facto  standard  for 
amateur  packet  radio,  used  extensively  over  radio-based  networks  world-wide 
since  the  1970's  [Ref.  2].  AX.25  is  the  data  link  layer  protocol  used  by  the  Naval 
Research  and  Development  (NRaD)  Battle  Force  Electronic  Mail  System  currently 
being  distributed  throughout  the  navy.  Throughput  over  radio-based  networks  can 
vary  according  to  the  bandwidth  allocated  to  the  channel.  High  Frequency  (HF) 
radios  with  a  3KHz  bandwidth  commonly  support  2400  bps. 
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Figure  4.4.  Radio-Based  WAN  Topology 


2.  Growth  Path 

Standard  networking  protocols  will  continue  to  be  used  internally  on  the 
wired  MH-53E  and  MOC  LANS.  The  transition  from  standard  wired  network  to 
wireless  networking  protocols  is  made  within  the  router.  As  a  result,  to  upgrade  to 
a  reliable-multicast  set  of  network/transport  protocols  requires  minimal  effort  and 
cost  as  only  the  portions  of  software  used  to  connect  the  routers  to  each  other  over 
the  radio-based  network  will  have  to  be  changed.  Multicast  protocols  will  make 
the  radio-WAN  much  more  scalable  and  robust.  To  get  there,  the  routers  need 
multicast  Internet  Protocol  (IP)  and  multicast  routing  protocols  such  as  the  multi¬ 
cast  version  of  Open  Shortest  Path  First  (M-OSPF)  upgrades.  The  key  issue  is  that 
these  upgrades  do  not  affect  any  of  the  sensors  in  the  aircraft,  the  decision  support 
processors  in  the  MOC,  or  the  content/format  of  the  data  being  passed  over  the 
radio-based  WAN  itself  It  simply  improves  the  performance  of  the  WAN  by 
providing  a  reliable  multicast-capable  network. 

F.  SUMMARY 

The  AMCM  tactical  Internet  can  be  implemented  today.  An  overview  of 
the  router  based  tactical  internet  with  the  modular  end  systems  attached  is  shown 
in  Figure  4.5. 
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Figure  4.5.  Proposed  AMCM  Tactical  Internet 
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V.  COMMON  NETWORKING  INTERFACES 


A.  INTRODUCTION 

The  Internetworked  AMCM  architecture  consists  of  five  common  inter¬ 
faces  to  attach  end  systems  to  the  tactical  internet.  These  interfaces  include: 

•  Local-Area  Network  (LAN)  Hardware  Interface 

•  Transmission  Control  Protocol  /  Internet  Protocol  (TCP/IP) 

•  Electronic  Mail  (E-Mail)  Envelope  Definition 

•  Common  Data  Definition 

•  Simple  Network  Management  Protocol  (SNMP)  Agent 

By  using  these  interfaces,  the  AMCM  C'^I  Information  System  will  be  inter¬ 
operable  with  tactical  networks  world  wide. 

B.  LAN  HARDWARE  INTERFACE 

The  local-area  network  (LAN)  hardware  interface  is  used  to  connect  the 
modular  components  to  the  LAN.  The  hardware  interface  ought  to  remain 
consistent  throughout  the  overall  system  as  much  as  possible  in  each  of  the  LAN 
environments  in  order  to: 

•  Provide  a  high  level  of  interoperability 

•  Reduce  costs 

•  Provide  a  path  to  connect  upgrades  or  additional  equipment 
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•  Leverage  technology  -  eompartmentalize  the  development  items 

(such  as  the  sonar)  behind  the  LAN  interface,  so  that  changes  to  the 
development  item  will  not  impact  the  rest  of  the  network. 

The  recommended  MH-53E  LAN  hardware  interfaee  is  the  IEEE  802.3, 
lOBase-T  Ethernet  set  of  standards  to  reduce  costs  and  improve  interoperability. 
Serial  connections  such  as  RS232,  RS449,  RS530  between  components  ought  to 
be  limited  and  progressively  eliminated  as  these  degrade  system  modularity  and 
flexibility. 

A  more  eomplex  LAN  is  required  for  the  MOC  as  it  will  be  used  to 
communicate  with  the  MH-53E  LANs  as  well  as  the  ship-based  or  ground-based 
environment  where  it  is  physieally  located.  The  MOC  LAN  will  have  a  multitude 
of  potential  connections  such  as  phone,  fiber.  Integrated  Services  Digital  Network 
(ISDN)  /  Broad  Band  ISDN,  satellite  and  possibly  even  other  radio  connections. 
Therefore,  both  FDDI  and  Ethernet  hubs  are  recommended  for  use  to  provide 
common  LAN  hardware  connections  for  the  assorted  equipment.  Such  hubs  are 
commercially  common  and  inexpensive. 

C.  TCP/IP 

The  second  common  interface  is  the  Transmission  Control  Protocol  Internet 
Protocol  (TCP/IP)  set  of  protocols  common  to  the  commercial  Internet.  IP  is 
introduced  in  RFC79I  [Ref  3]  and  TCP  is  introduced  in  RFC793  [Ref  4].  TCP/IP 
is  an  open,  standards-based  network  architecture  that  is  divided  into  layers  and 
protocols. 

1.  TCP/IP  Network  Architecture 

Networks  are  organized  as  a  series  of  layers  to  reduce  complexity.  The 
purpose  of  each  layer  is  to  provide  services  to  the  layers  that  are  above  it,  without 
the  upper  layer  having  to  manage  the  details  of  how  the  lower  layer  actually 
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provides  the  services.  Each  layer  has  protocols,  i.e.  sets  of  rules  that  govern  how 
the  services  are  provided.  These  layers  and  associated  protocols  are  "stacked"  on 
top  of  each  other.  Each  layer  passes  information  to  the  layer  immediately  below  it 
until  the  lowest  layer  (i.e.  the  physical  layer)  is  reached.  There  the  information  is 
put  onto  a  physical  medium  and  transported  over  the  network.  The  physical 
medium  can  be  wireless,  twisted  pair,  fiber,  cable,  etc.  The  TCP/IP  network 
architecture  is  arranged  as  follows: 


Layer 

Application 

Transport 

Internet 

Physical/data  link 


Protocols 

SMTP,  MIME,  SNMP 

TCP 

IP 

Ethernet  (IEEE802.3),  FDDI/  AX.25' 


2.  Layers  and  Protocols 

The  Physical/data  link  layer  provides  the  transfer  of  information  from  the 
host  to  the  network.  The  Internet  (internetwork)  layer  permits  a  host  to  inject 
packets  into  any  network  and  have  them  travel  independently  to  the  destination, 
possibly  over  different  networks.  The  packets  may  arrive  in  any  order,  as  they  will 
be  sorted  as  required  at  the  receive  end.  The  internetwork  layer  defines  an  official 
packet  format  and  protocol  called  IP  (Internet  Protocol).  The  job  of  the  inter¬ 
network  layer  is  to  deliver  packets  where  they  are  supposed  to  go  across  multiple 
networks. 


'SMTP  is  Simple  Mail  Transfer  Protocol  (RPC822).  MIME  is  Multimedia  Internet 
Mail  Extensions.  SNMP  is  Simple  Network  Management  Protocol.  802.3  is  the  IEEE 
committee  that  standardizes  CSMA/CD  LAN  protocols.  FDDI  is  Fiber  Distributed  Data 
Interface,  AX.25  is  by  Amateur  Radio  Relay  League,  Newington,  CT. 
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The  layer  above  the  internetwork  layer  in  the  TCP/IP  model  is  the  Transport 
layer.  This  layer  allows  source  and  destination  hosts  to  carry  on  a  conversation. 
The  Transmission  Control  Protocol  (TCP)  is  a  reliable  connection-oriented 
protocol.  TCP  was  specifically  designed  to  provide  a  reliable  end-to-end  byte 
stream  over  an  unreliable  network,  which  means  it  guarantees  an  in-order,  bit 
perfect  data  transfer  from  sender  to  receiver.  The  sending  TCP  process  takes  an 
incoming  data  stream  and  divides  it  into  packets  and  passes  them  to  the  inter¬ 
network  layer.  The  receiving  computer  TCP  receives  packets  from  the  network 
layer  and  reassembles  the  packets  into  a  data  stream.  TCP  adds  support  to  detect 
errors  or  lost  data  and  to  trigger  retransmission  until  the  data  is  correctly  and 
completely  recovered.  TCP  also  provides  flow  control  to  ensure  the  packets  don’t 
arrive  faster  than  the  receiver  can  manage  them.  All  TCP  connections  are  point-to- 
point.  TCP  does  not  support  multicasting  or  broadcasting.  However,  since  TCP  is 
the  most  common  transport  protocol,  TCP  provides  a  base  which  will  allow  an 
easy  upgrade  to  a  reliable  multicast  transport  layer  protocol  in  the  future.  Numer¬ 
ous  protocols  are  being  developed  to  augment  TCP  and  are  designed  to  be 
compatible  with  TCP's  current  design. 

The  final  layer  is  the  Application  Layer.  It  contains  the  high-level  protocols 
such  as  Simple  Network  Management  Protocol  (SNMP),  Simple  Mail  Transfer 
Protocol  (SMTP),  Multipurpose  Internet  Mail  Extensions  (MIME),  and  Secure 
Multipurpose  Internet  Mail  Extensions  (S/MIME). 

The  TCP/IP  protocol  suite  is  the  de  facto  standard  of  the  networking  world. 
It  is  robust.  It  dynamically  adjusts  routing  of  packets  to  accommodate  failures  in 
the  network  channels.  TCP/IP  allows  data  to  pass  over  very  large  networks  with 
little  management.  Other  network  protocols  and  dissimilar  equipment  are 
emphatically  not  recommended. 
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D.  ELECTRONIC  MAIL  DEFINITION 


The  third  common  interface  is  the  e-mail  definition.  Electronic  mail  makes 
it  possible  to  easily  encapsulate  the  desired  information  inside  an  addressable 
envelope  and  transport  this  information  to  more  than  one  destination. 

1.  User  Agents  and  Daemons 

Electronic  mail  (e-mail)  systems  normally  consist  of  two  subsystems:  the 
user  agent  which  enables  users  to  send  and  read  e-mail,  and  the  message  transfer 
agent,  which  move  the  message  from  sender  to  receiver.  The  e-mail  message 
transfer  agents  (e-mail  daemon)  are  usually  pre-installed  on  a  processing  platform 
as  part  of  the  e-mail  system  included  with  the  operating  system.  The  message 
transfer  agents  are  daemons  responsible  for  delivering  mail  through  the  system, 
transparent  to  the  user.  The  user  agents  are  typically  local  programs  that  act  as  a 
graphical  or  command  based  interface  with  an  e-mail  system.  Automated  user 
agents  are  also  widely  available  which  can  assemble  data  into  a  complete  message 
and  forward  the  message  to  the  e-mail  daemon  for  delivery. 

2.  Envelope 

The  e-mail  envelope  contains  all  the  information  needed  for  transporting  the 
message  including  destination  address,  security,  and  priority.  The  enveloping 
information  is  independent  of  the  content  of  the  message  itself.  The  envelope 
simply  encapsulates  the  message  and  .provides  the  necessary  routing  information 
for  the  message  transfer  agents.  The  message  inside  the  envelope  contains  the 
header  and  the  body.  The  header  provides  control  information  for  the  user  agent 
and  the  body  contains  the  contents  of  the  message  itself. 

3.  SMTP  &  MIME 

In  1982  the  ARPANET  e-mail  proposals  were  published  as  RFC821  (trans¬ 
mission  protocol)  [Ref.  5]  and  RFC822  [Ref.  6]  (message  format)  [Ref.  7:p.  644]. 
Both  of  these  have  since  become  the  de  facto  Internet  standards.  Today,  RFC821 
is  commonly  known  as  Simple  Mail  Transfer  Protocol  (SMTP).  E-mail  systems 
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have  evolved  since  RFC822  began  as  basic  ASCII  text  e-mail.  Multimedia  exten¬ 
sions  have  been  added  to  support  numerous  application  requirements.  RFC  1521 
[Ref.  8]  presents  the  Multipurpose  Internet  Mail  Extensions  (MIME).  MIME  is 
based  on  the  RFC822  format,  but  adds  structure  to  the  message  body  and  defines 
encoding  rules  for  non-ASCII  messages  such  rich  text,  imagery,  or  video.  There¬ 
fore,  MIME  messages  can  be  sent  using  the  existing  native  e-mail  programs  and 
protocols.  All  that  must  be  changed  are  the  sending  and  receiving  user  agent 
programs  which  can  easily  be  done  at  the  user  level.  MIME  messages  may 
include  the  following  type  and  subtype  as  shown  in  Figure  5.1  [Ref.  7:p.  655]: 


TYPE 

SUBTYPE 

DESCRIPTION 

Text 

Plain 

Unformatted  text 

Richtext 

Text  including  simple  formatting  commands 

Image 

Gif 

Still  picture  in  Gif  format 

JPEG 

Still  picture  in  JPEG  format 

Audio 

Basic 

Audible  sound 

Video 

MPEG 

Movie  in  MPEG  format 

Application 

Octet-Stream 

An  uninterpreted  byte  sequence 

Postscript 

A  printable  document  in  postscript 

Message 

RFC822 

A  MIME  RFC822  standard  message 

Partial 

Message  has  been  split  for  transmission 

External-body 

Message  itself  must  be  fetched  over  the  net 

Multipart 

Mixed 

Independent  parts  in  the  specified  order 

Alternative 

Same  message  in  different  formats 

Parallel 

Parts  must  be  viewed  simultaneously 

Digest 

Each  part  complete  RFC822  message 

Figure  5.1.  MIME  E-mail  Message  Types  and  Subtypes  Deflned  in 
RFC1521 
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Since  our  project  goal  is  to  maximize  the  number  of  COTS  standard  e-mail 
processes  used  in  order  to  minimize  the  amount  of  custom  software  required,  we 
can  map  all  the  AMCM  data  needs  into  these  generic  formats.  MIME  protocol 
extensions  provide  RFC 822  common  addressable  envelopes  that  may  contain  text 
based  MCMR  reports,  mine-like  contact  positions,  aircraft;  flight-following/ 
position  location  information  (PLI),  imagery  and  even  video. 

4.  Message  Assembly 

Finally  some  custom  software  is  needed  to  gather  information  fi*om  various 
sensors  and  processors  located  on  the  MH-53E  LAN  and  send  the  information  to 
the  e-mail  user  agent  for  assembly  inside  the  body  of  the  message.  This  informa¬ 
tion  may  include  a  JPEG  sonar  image  of  a  mine-like  object,  TARLOC  position, 
aircraft  PLI,  time  stamp  etc.  The  software  processes  may  be  programmed  to 
automatically  trap  information  from  various  sensors/processors  at  a  desired  inter¬ 
val  or  only  when  tasked  to  do  so  by  the  user.  For  example,  when  the  sonar  console 
operator  marks  a  mine-like  contact  by  pressing  the  priority  write  button  on  the 
sonar  console,  all  applicable  information  is  then  trapped  and  forwarded  to  the  e- 
mail  user  agent  for  assembly.  The  user  agent  program  receives  information  from 
the  various  sensors  which  it  then  encapsulates  with  the  mine-like  object  video  or 
image  (binary  large  object)  file  inside  the  addressable  e-mail  envelope.  The 
message  is  then  constructed  using  any  combination  of  the  following  format  types 
shown  in  Figure  5.2. 
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TYPE 

SUBTYPE 

INFORMATION  CONTAINED 

Text 

Plain 

GPS:  (  Latitude,  Longitude,  Date,  Time, 

Altitude,  Heading,  Navigational  Error) 

A/C:  (Identification,  Heading,  Skew,  Mission) 
Sonar:  (Type,  Speed,  Depth,  Altitude) 

Contact:  (MILC  #,  Type  of  Mine,  etc.) 
Environmental:  (Bottom  Conditions,  etc.) 

Image 

JPEG 

Sonar  imagery  (snippet)  in  JPEG  format 

Video 

MPEG 

Sonar  video  in  MPEG  format 

External-body 

A  Video  Segment/  Image/Description  of  this 
contact  can  be  retrieved  if  desired. 

Multipart 

Mixed  Text, 
Image,  etc. 

Plain  Text:  lat/long,  time,  A/C  ID,  MILC# 

Image:  JPEG  image  of  MILC 

Figure  5.2.  AMCM  C**!  Information  System  Message  Structure 

Other  messages  may  be  constructed  as  well  including  reports  such  as  MCMR-12, 
MCMR-16,  and  Flight  Following  PLI  Report  by  using  the  text  type.  By  using  the 
External  Body  subtype,  large  files  (Video/Imagery)  do  not  need  to  be  transferred 
to  all  recipients.  Recipients  may  be  notified  where  these  files  are  stored  (i.e.  in 
the  MOC)  2ind  they  may  transfer  these  files  securely  fi'om  the  storage  site  as 
needed  as  long  as  they  have  the  proper  access. 

5.  Secure  E-mail 

In  addition  to  using  KG-84C  to  provide  link  encryption  over  the  radio 
WAN,  e-mail  may  also  be  encrypted  between  nodes  on  each  LAN  as  several 
alternatives  can  be  used  to  provide  e-mail  security.  If  desired,  e-mail  over  the 
radio-based  WAN  between  the  MH-53E  user  agent  and  the  MOC  user  agent  can 
also  use  these  tools  to  provide  data  confidentiality  and  authenticity.  There  are 
least  four  competing  choices  of  secure  e-mail.  These  include  Pretty  Good  Privacy 
(PGP),  Secure  Multipurpose  Internet  Mail  Extensions  (S/MIME),  MIME  Object 
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Security  Services  (MOSS),  Message  Security  Protocol  (MSP)  designed  for  X.400. 
Fortunately,  the  issue  is  modular  as  only  the  participating  e-mail  user  agent’s  are 
affected,  none  of  the  sensors  or  decision  support  software.  Therefore  any  of  these 
secure  e-mail  methods  can  be  selected  with  little  downside. 

(S/MIME)  was  recently  developed  to  add  privacy,  authentication,  and 
tamper-proof  parameters  to  MIME  (RFC  1 521).  Prior  to  S/MIME,  no  authentica¬ 
tion,  confidentiality,  or  data  integrity  properties  were  provided  in  SMTP,  RFC822, 
or  MIME.  However,  S/MIME  provides  secure  communications  between  disparate 
or  even  unknown  mail  platforms.  S/MIME  is  based  on  RSA  Public  Key  Crypto¬ 
graphy  Standards  (PKCS)  [Ref  9]  and  provides  a  digital  signature  and  a  digital 
envelope.  A  digital  signature  provides  authentication  and  a  digital  envelope 
encrypts  the  contents  of  the  message.  This  ensures  message  can  only  be  read  by 
the  intended  recipient.  The  digital  envelope  uses  an  adjustable  cipher  length  key 
with  an  algorithm  like  DES  or  RC2.  Numerous  vendors  have  adopted  this 
standard  including  Microsoft,  Lotus,  Netscape  and  Qualcomm.  For  example, 
Qualcomm's  Eudora  Version  3.0  E-mail  program  added  S/MIME  to  the  applica¬ 
tion  layer.  Mastercard  and  Visa  also  use  the  same  PKCS  #7  Cryptographic 
Message  Syntax  standard  as  well. 

6.  X.400 

Two  years  after  RFC82 1/822  was  presented,  X.400  appeared  as  CCITT 
recommendation,  which  was  again  modified  in  1988.  X.400  is  based  on  ASN.l 
encodings,  not  text  like  SMTP,  RFC822,  and  MIME.  After  a  decade  of  competi¬ 
tion,  e-mail  systems  based  on  RFC822  are  widely  used,  whereas  those  based  on 
X.400  have  mostly  disappeared  (despite  this  fatal  defeat,  X.400  is  surprisingly 
proposed  as  the  e-mail  standard  for  SPAWARs  MIW  C^ISR  Systems  Architec¬ 
ture).  Numerous  compatibility  problems  remain  between  1984  X.400  and  1988 
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X.400  versions.  The  reason  for  RFC822's  overwhelming  success  is  that  X.400  is 
so  poorly  designed  and  complex  that  it  is  difficult  to  implement  well  [Ref  7:p. 
646].  MIME  is  a  direct  result  of  the  difficulty  involved  attempting  to  bring  X.400 
to  the  commercial  market.  In  the  end,  it  was  easier  to  fix  SMTP  and  develop 
MIME  instead.  X.400  message  addresses  also  require  lengthy  attribute  fields 
which  are  unnecessary  and  far  more  cumbersome  than  the  normal  usemame@ 
hostname,  subnetwork  format  on  used  by  RFC 822/MIME/  SMIME.  However  it  is 
possible  to  send  e-mail  between  X.400  and  RFC822-based  e-mail  systems,  though 
conversion  between  is  required  and  most  commonly  done  using  special  gateways. 
However  such  a  gateway  might  easily  be  put  into  the  MOC  to  access  the  X.400/ 
DMS  customers  as  required,  while  MIME  should  be  used  over  the  rest  of  the 
radio-based  portion  of  the  WAN  in  order  to  reduce  address  overhead. 

In  theory,  all  that  can  be  done  with  MIME  can  also  be  done  with  X.400,  but 
the  user  base  and  product  support  are  not  as  widespread  for  X.400.  Given  the 
choice  between  a  simple  widespread  working  model  and  a  supposedly  wonderful 
but  non-working  X.400  system,  most  implementers  chose  RFC822  (including 
NRaD  which  uses  Qualcomm's  Eudora,  a  RFC822  based  e-mail  program  for  its 
Battle  Force  E-mail  system).  The  bottom  line  is  that  an  IP-based  network  carries 
IP  datagrams  and  is  not  concerned  whether  the  e-mail  application  is  based  on 
RFC822,  MIME,  S/MIME,  X.400  or  all  of  the  above.  However,  any  e-mail 
application  must  be  easy  to  implement,  or  it  won’t  be  used  effectively.  Therefore 
the  proposed  AMCM  system  is  based  in  RFC 822  and  MIME. 

E.  COMMON  DATA  DEFINITION 

The  purpose  of  using  common  data  definitions  is  to  ensure  that  the  informa¬ 
tion  can  be  input,  read,  modified,  and  used  on  multiple  platforms,  independent  of 
manufacturer  or  operating  system.  It  is  absolutely  essential  that  the  data  elements 
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be  defined  consistently  throughout  MIW  and  other  communities.  Standard  data 
definitions  and  image  formats  must  be  used  in  order  to  interchange  information 
over  a  cross-platform,  community-wide,  relational  database.  Common  data 
definitions  provide  data  interoperability  between  sensor,  processor,  decision 
support  modules  and  the  user.  For  example,  minehunting  information  gathered 
from  multiple  sensors  is  used  by  the  Target  Location  (TARLOC)  program  to 
calculate  mine-like  object  locations.  This  calculation  can  be  done  by  a  processing 
module  on  the  AMCM  platform  itself,  by  a  processing  module  in  the  MOC,  or  by 
a  JMCIS/MEDAL  station  without  requiring  any  conversion,  as  long  as  the  data  is 
properly  defined.  This  can  only  be  done  seamlessly  if  the  sensor  data  is  provided 
in  the  proper  format  prior  to  entry  into  the  TARLOC  program.  The  most 
expedient  and  efficient  method  is  to  put  the  information  in  the  proper  format  at  the 
entry-level  point  to  the  network.  For  example,  the  data  elements  that  must  be 
properly  defined  to  catalog  and  calculate  a  contact's  location  using  TARLOC 
includes  minelike  contact  number  (mile#),  timestamp,  position  (latitude  & 
longitude),  altitude  (alt),  navigational  error  (e  or  a),  aircraft  heading/skew,  sonar 
speed/depth  and  cable  length  as  shown  in  Figure  5.3. 


mile# 

time 

Lat 

Long 

e 

A/C 

A/C 

A/C 

sonar 

sonar 

cable 

o 
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skew 

alt 

speed 

depth 

length 

Figure  5.3.  Timestamp  Data  Elements 

These  data  elements,  once  properly  defined,  may  be  grouped  into  the  text 
type  category  for  message  composition  and  included  as  an  e-mail  message. 
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Additional  types  of  data  such  as  imagery,  audio  and  video  may  be  attached  and 
forwarded  as  well. 

JMCIS  is  an  example  of  a  tactical  decision  aid  that  uses  such  data  defini¬ 
tions.  It  uses  a  common  operating  environment  with  strict  data  definitions  to 
ensure  interoperability  between  segments  such  as  MEDAL.  AMCM  O'*!  Informa¬ 
tion  System  will  include  JMCIS/MEDAL  as  a  node  on  the  network  in  order  to 
achieve  the  tactical  interoperability  objectives  desired.  To  do  so  seamlessly,  the 
JMCIS  data  element  definitions  must  be  used  as  much  as  possible.  Because  the 
JMCIS  data  element  definitions  are  used  by  the  originating  host  to  draft  the 
original  mine-like  contact  reports,  the  data  is  compatible  for  MIW  MEDAL  data¬ 
base  entry  as  soon  as  the  mine-like  contact  is  determined  to  be  valid  without 
requiring  data  element  conversion. 

F.  SNMP 

Simple  Network  Management  Protocol  (SNMP)  presented  in  RFC  1448 
[Ref  10  ],  provides  a  systematic  way  of  monitoring  and  managing  a  computer 
network.  The  SNMP  managed  network  model  consists  of  four  components:  [Ref 
7:p.  632] 

1 .  Managed  Nodes  (which  contain  management  agents) 

2.  Managed  Stations 

3 .  Management  Information  (which  runs  a  management  platform) 

4.  A  management  protocol 

These  components  are  examined  in  the  following  sections. 
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1.  SNMP  Agent 

To  be  directly  managed  by  SNMP,  the  node  must  be  able  to  run  a  SNMP 
management  process  called  an  SNMP  agent.  Each  agent  maintains  a  local  data¬ 
base  of  variables  that  describe  its  status  and  affect  its  operation.  All  of  these 
variables  (objects)  are  maintained  in  the  Management  Information  Base  (MIB). 
The  typical  managed  nodes  include  routers,  bridges,  hosts  etc.  However,  any 
device  that  is  capable  of  communicating  information  on  its  own  status  may  also  be 
part  of  a  SNMP  managed  network.  SNMP  agent  "kits"  are  available  for  numerous 
devices,  including  uninteruptible  power  supplies.  Kits  may  also  be  developed  for 
sonobouys,  radio  navigation  receivers,  modems,  radios,  even  in  sonar  console 
processors. 

2.  SNMP  Management  Station 

Network  management  is  done  from  management  stations  which  are  nothing 
more  than  computers  running  special  management  software.  The  management 
stations  contain  processes  that  communicate  with  the  agents  over  the  network  by 
issuing  commands  and  eliciting  responses.  The  complexity  of  this  system  resides 
in  the  management  station.  This  keeps  the  agents  as  simple  as  possible  and 
minimizes  the  workload  on  the  device  hosting  the  agent  software.  The  manage¬ 
ment  station  is  able  to  interact  with  the  agents  using  the  SNMP  protocol.  By  using 
SNMP  protocol,  the  management  station  is  able  to  query  the  agent  and  if 
authorized,  change  the  variables  that  describe  the  state  of  the  agent.  Normally  the 
management  station  sends  a  request  to  the  agent  asking  for  information  or 
commanding  it  to  update  its  state.  The  agent  usually  replies  with  the  information 
or  confirms  that  its  state  has  been  changed  as  requested.  Errors  can  also  be 
reported  if  a  incorrect  variable  is  used.  Seven  different  message  types  can  be  sent 
using  SNMP.  Six  are  from  the  initiator  and  the  seventh  is  the  response  message 
from  the  agent  as  shown  in  Figure  5.4  below:  [Ref.  7:p.  643] 
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MESSAGE 

DESCRIPTION 

Get-request 

Requests  the  value  of  one  or  more  variables 

Get-next-request 

Requests  the  variable  following  this  one 

Get-bulk-request 

Fetches  a  large  table 

Set-request 

Updates  one  or  more  variables 

Inform-request 

Agent-to-manager  message  describing  local  MIB 

SnmpV2-trap 

Agent-to-manager  trap  report 

Response  message 

Response  to  request  message 

Figure  5.4.  SNMP  Message  Types 

Assets  on  a  SNMP  managed  networks  can  be  monitored  and  remotely  managed 
from  a  central  location. 

G.  SUMMARY 

Common  interfaces  are  critical  to  the  success  of  the  any  information 
system.  The  commonly  defined  data  elements  allow  data  to  be  read  and  used  on 
different  TDA’s,  databases,  processors  etc.  without  requiring  conversion  or  manual 
reentry.  The  LAN  hardware  interfaces  ensure  compatibility  and  flexibility 
between  the  modular  components.  The  Envelope  Definition  defines  the  wrapper, 
whose  contents  may  be  in  text,  imagery  or  even  video  segments.  TCP/IP  and 
SNMP  Protocols  are  used  to  manage  the  network  and  provide  compatibility  to 
access  information  over  networks  worldwide.  The  AMCM  Information 
System  architecture  can  accommodate  any  sensor  or  decision  support  computer 
that  subscribes  to  these  interfaces,  i.e.  any  system  that  has  built-in  or  added 
Internet  compatibility. 
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VI.  REQUIREMENTS  PERSPECTIVE 


A.  INTRODUCTION 

This  chapter  presents  the  overall  mission  requirements  and  the  tradeoffs 
involved  in  achieving  these  requirements. 

B.  OVERVIEW 

Given  many  requirements,  it  is  important  to  keep  the  larger  goal  in  mind  at 
all  times  and  to  translate  local  actions  into  global  results.  However,  it  is  also 
imperative  to  realize  that  there  is  no  single  larger  picture.  There  are  numerous 
larger  pictures  to  consider,  each  larger  than  the  predecessor.  For  example,  a  local- 
area  network  may  be  formed  by  integrating  the  G^I  assets  in  the  Mobile  Operations 
Center  (MOC).  Another  local-area  network  (temporarily  palletized)  can  be  formed 
by  integrating  the  C'*!  assets  on  board  the  AMCM  helicopter.  Finally,  integration 
of  various  communications  and  cryptographic  equipment  into  each  of  these  LAN's 
to  form  a  radio-based  wide-area  network  that  passes  data  between  the  mobile  MH- 
53E  LAN  and  the  mobile  operations  center  (MOC)  LAN  forms  an  even  wider 
information  system.  Finally,  the  system  may  be  further  expanded  as  additional 
MH-53E  mobile  LAN's  and  shore-  based  LAN's  are  added  to  the  overall  system. 
The  picture  will  continually  evolve  and  grow  in  scope.  However,  to  ensure  that 
the  system  is  not  limited  beyond  the  immediate  mental  focus  of  the  designer,  the 
system  must  be  designed  from  the  most  basic  level  to  use  open  standards  and  an 
open  architecture  so  that  it  is  scalable  and  flexible  at  all  levels,  now  and  in  the 
future. 

C.  SOLVING  THE  RIGHT  PROBLEM 

Part  of  the  system  design  problem  is  the  fact  that  system  will  be  constantly 
upgraded  in  ways  that  no  single  individual  can  foresee  in  any  detail.  Thus  the  rule: 


43 


"Part  of  systems  engineering  design  is  to  prepare  for  changes  so  that  they  can  be 
gracefully  made  and  still  not  degrade  the  other  parts"  [Ref  1 1  :p.  5] 

Unfortunately,  many  solutions  are  often  offered  that  can  solve  the  wrong 
problem  correctly.  Systems  Engineering  involves  solving  the  right  problem.  This 
thesis  has  established  that  the  proper  focus  is  on  the  data,  not  the  data  link.  The 
solution  to  the  problem  is  based  therefore  on  determining  what  data  flows  are 
required  between  each  LAN. 

D.  STATED  REQUIREMENTS 

The  MIW  C^I  Requirements  Document  states  that  "as  a  minimum,  a  data 
link  will  provide  the  following: 

a.  MCM  asset  position 

b.  Parameters  to  compute  trailback  and  offset  of  MCM  gear. 

c.  MCM  equipment  settings/performance  data,  when  sweeping. 

d.  Sensor  video  and/or  digital  sonar  image  data,  when  hunting 
(primarily  for  unmanned  systems)"  [Ref  12:p.  2] 

Sensor  video  and  /or  digital  sonar  image  data  is  also  listed  as  a  periodic  or 
as-  needed  transmission  under  the  MIW  C*!  Requirements  Document.  Video  is 
not  stated  as  a  clear  requirement.  The  wording  of  the  statement,"video  and/or 
digital  sonar  image  data,"  implies  that  imagery  is  an  acceptable  substitute  for 
video. 

PMS-210,  (the  AMCM  Program  Executive  Office),  has  stated  that  the 
priorities  for  the  system  are  as  follows: 
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1 .  Real-time  aircraft  position/location  information  (PLI), 

2.  Near-real  time  sonar  data, 

3.  Over-the-horizon  range  is  desired. 

"Sonar  data"  includes  mine-like  contact  position  information  and  imagery  of  mine¬ 
like  objects  or  video  if  possible. 

E.  TACTICAL  OBJECTIVES 

Before  examining  the  differences  between  video  and  sonar  imagery,  we 
shall  reconsider  the  purpose  of  the  AMCM  squadron.  In  many  cases  AMCM  acts 
in  the  role  of  precursor  sweeping  and  fast  reconnaissance.  The  sonars  employed 
by  the  AMCM  assets  are  for  search  and  not  classification.  Therefore,  the  purpose 
AMCM  mine-hunting  missions  is  not  to  analyze  a  mine-like  object  in  an  attempt  to 
identify  mine-type.  Rather  AMCM  mine-hunting  missions  are  tasked  to  provide  a 
quick  surveillance  of  the  area  to  confirm  the  presence  and  location  (if  possible)  of 
mine-like  objects.  If  mine-like  objects  are  discovered,  other  assets  may  be 
employed  in  order  to  destroy  or  neutralize  them.  AMCM  may  also  be  redeployed 
to  revisit  the  area  with  equipment  specifically  designed  to: 

•  Cut  the  cable  of  a  moored  mine 

•  Use  acoustic/magnetic  influence  devices  to  actuate  an  influence  mine 

The  primary  information  that  must  be  passed  is  an  indication  of  whether  or  not 
mine-like  objects  are  present  and,  if  present,  the  location  of  these  objects.  Armed 
with  this  information  the  Commander  can  proceed  to  the  next  step:  avoidance, 
destruction,  or  neutralization. 
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F.  REAL  REQUIREMENT 


The  real  requirement  is  to  deliver  a  sufficient  amount  of  "critical  informa¬ 
tion"  in  near-real  time  latency  period  (measured  in  tens  of  seconds)  in  order  to 
provide  a  near-real  time  mine  avoidance  capability  to  the  fleet.  The  system  should 
not  care  not  care  whether  the  data  format  is  text,  video  or  single  frame  imagery, 
but  only  that  the  critical  information  is  delivered  in  near-real  time  in  a  usable  form 
to  all  levels  where  the  necessary  decisions  must  be  made.  In  order  to  achieve  this 
required  objective,  "critical  information"  must  be  explicitly  defined  and  efforts 
must  be  made  to  minimize  the  amount  of  time  that  it  takes  to  process,  analyze  and 
act  upon  this  information. 

1.  Critical  Information 

Critical  information  consists  of  information  that  is  crucial  to  success. 
Information  crucial  to  success  in  AMCM  includes  the  following: 

a.  Mine-like  object  position  information.  Crucial  for  prosecu¬ 
tion  by  surface  MCM  and  EOD  assets  and  for  avoidance  of  mine  danger  areas  by 
shipping. 

b.  AMCM  and  surface  based  MCM  identification  and  asset 
positions.  Crucial  for  deconfliction  and  safety  of  flight. 

Essentially,  either  mine-like  objects  are  confirmed  in  the  operating  area  or 
are  failed  to  be  confirmed  as  they  may  not  be  detected  or  actuated  due  to  variety 
of  reasons  including  malfunctioning  equipment,  burial,  navigation  errors,  etc. 
However,  once  detected,  an  accurate  mine-like  object  position  report  must  be 
made  available  as  soon  as  possible. 

2.  Near-Real  Time  Transfer  of  Information 

The  only  way  to  have  a  near-real  time  mine-avoidance  capability  is  to  have 
the  information  that  makes  mine-avoidance  possible  available  in  near-real  time. 
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Therefore  the  objective  is  to  minimize  the  amount  of  time  required  to  process  and 
transfer  the  information  from  the  sensor  to  the  decision  maker.  Numerous  inter¬ 
related  issues  are  involved  in  achieving  this  objective.  These  issues  include,  but 
are  not  limited  to  the  following:  range,  throughput,  processing,  format,  packaging, 
scalability,  manpower,  security,  available  technology,  and  cost. 

These  issues  are  discussed  in  following  section  as  they  are  requirements 
that  must  be  considered  in  conjunction  with  the  near-real  time  capability  issue. 

G.  ENGINEERING  ISSUES 

The  following  issues  must  be  considered  in  conjunction  with  the  near-real 
time  capability  requirement. 

1.  Range 

Range  is  a  crucial  issue  involved  in  the  delivery  of  critical  information  to  all 
levels  where  the  necessary  decisions  must  be  made.  If  the  MH-53E  AMCM  asset 
is  out  of  range,  no  information  will  be  delivered  as  connectivity  cannot  be  estab¬ 
lished  over  the  radio-based  WAN.  Ultra  High  Frequency  (UHF)  radios  are  limited 
to  line-of-sight  (LOS)  communications.  During  AMCM  operations,  LOS  range  is 
typically  20  nautical  miles.  Unless  satellite  communications  or  High  Frequency 
(HF)  radios  are  used,  information  will  not  be  available  in  near-real  time  in  ranges 
beyond  LOS.  HF  radio  communications  using  surface  waves  typically  provide 
over-the-horizon  (OTH)  ranges  of  100  nautical  miles.  AMCM  operations  require 
OTH  connectivity  as  operations  are  often  performed  in  ranges  beyond  LOS. 

2.  Throughput 

Throughput  is  a  crucial  issue  as  it  directly  impacts  the  speed  in  which 
information  can  be  delivered  over  the  radio-based  WAN.  Throughput  is  affected 
by  numerous  factors  such  as  compression,  modulation,  bandwidth  of  the  data 
channel,  and  the  quality  of  the  communications  link  itself.  Typically,  as  any  of 
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these  factors  increase,  so  does  the  data  rate.  Standard  HF  channels  have  a  band¬ 
width  of  3  KHz  and  support  data  rates  of  2.4  Kbps  (less  than  a  typical  home 
telephone  modem).  This  rate  may  vary  due  to  error  correction,  link  quality, 
protocol  performance  etc.,  but  the  amount  of  information  that  HF  can  transfer  in 
near-real  time  is  extremely  limited  in  comparison  to  UHF. 

Standard  UHF  channels  have  a  bandwidth  of  25  KHz  and  support  data  rates 
of  16Kbps.  However,  UHF  radios  and  modems  are  readily  available  that  modify 
the  standard  UHF  channel  bandwidth  to  support  near-real  time  data  rates  from 
Kbps  to  2Mbps.  Due  to  the  higher  throughput,  UHF  radio-based  systems  are  able 
to  support  a  wider  range  of  multimedia  applications  such  as  audio,  imagery  and 
video. 

Due  to  HF  radio  communications  restricted  throughput,  HF  usage  should 
be  limited  to  text  based  messages  and  small  single  frame  images  for  supporting 
near-real  time  operations.  Therefore  imagery,  not  video,  is  the  preferred  method 
of  transporting  mine-like  object  images  which  are  to  be  displayed,  as  HF  commun¬ 
ications  will  not  support  "video"  throughput  requirements. 

3.  Processing 

The  best  way  to  minimize  the  amount  of  time  required  to  process  informa¬ 
tion,  is  to  process  as  much  as  possible  at  the  source.  This  reduces  the  amount  of 
unprocessed  information  that  must  be  transferred  and  processed  upon  arrival. 

Only  pertinent  information  is  transferred  for  further  evaluation  by  the  decision 
nodes.  Less  transfer  time  and/or  throughput  is  required  through  bottleneck  links 
because  less  data  must  be  transferred. 

There  are  several  options  available  to  increase  the  amount  of  processing  at 
the  source.  The  biggest  impact  would  be  through  the  use  of  computer-aided 
detection  (CAD)  algorithms  on  board  the  MH-53E.  This  will  provide  automated 
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on-site  real-time  sonar  video  processing  in  addition  to  the  sonar  operator’s  manual 
scanning  process.  The  calculation  of  mine-like  object  position  reports  using 
information  from  the  various  sensors  can  also  be  processed  on-board  the  MH-53E. 
This  will  further  reduce  the  amount  of  sensor  information  which  must  be  passed 
over  the  radio-based  WAN. 

4.  Format 

The  critical  information  must  be  in  the  proper  format  so  that  the  information 
can  be  directly  analyzed  by  the  decision  maker.  This  can  be  accomplished  in  near- 
real  time  as  long  as: 

•  The  information  is  properly  defined 

•  The  information  is  in  a  format  that  is  usable  upon  delivery  without 
requiring  multiple  conversions 

The  format  of  the  data  can  be  either  text,  imagery,  audio  or  video  depending 
on  the  ability  of  the  communications  channel  to  support  delivery  in  near-real  time. 
The  format  must  be  applicable  to  the  path  used  for  delivery.  The  critical  informa¬ 
tion  must  be  converted  (i.e.  from  video  to  imagery  or  from  imagery  to  text  based 
position  reports)  if  the  channel  cannot  support  near-real  time  delivery  of  the 
information  in  its  original  format. 

5.  Packaging 

In  order  for  the  information  to  be  available  in  near-real  time,  all  relevant 
information  must  first  be  gathered  and  packaged  together.  Proper  packaging 
includes  the  ability  to  contain  and  combine  all  relevant  data  independent  of  its 
format,  i.e.  video,  audio,  text  or  imagery.  For  example,  a  mine-like  object’s 
image,  position,  time,  etc.  must  be  contained  within  the  same  package.  The 
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package  must  be  addressable  and  secure  to  ensure  near-real  time  delivery  of 
information  to  decision  makers. 

6.  Scalability 

The  system  must  be  able  to  evolve  as  more  assets  are  added  to  the  overall 
network  without  reducing  the  near-real  time  performance  capability  desired.  The 
open  architecture  ensures  that  the  individual  MH-53E  assets  are  capable  of 
performing  as  much  of  the  processing  efforts  as  possible  so  as  not  to  overload  the 
processing  capabilities  in  the  MOC.  The  use  of  open  standards  throughout  each  of 
the  networks  ensure  that  the  system  itself  can  easily  evolve  as  individual  compon¬ 
ents  or  software  upgrades  become  available  without  causing  cascading  changes 
between  modules. 

7.  Manpower 

Additional  manpower  is  not  available  in  the  MOC  or  MH-53E  to  assist  in 
the  near-real  time  processing  or  delivery  of  critical  information.  As  numerous 
AMCM  operations  forward  critical  information  to  the  MOC  in  near-real  time, 
information  overload  is  possible  unless  the  data  flows  are  minimized  to  contain 
only  relevant  information  which  is  ready  for  use  by  decision  makers  upon  arrival. 
No  further  action  should  be  required  to  the  critical  information  as  such  actions  are 
potential  bottlenecks  to  the  information  distribution  process.  Considerable  life- 
cycle  savings  are  possible  as  manning  requirements  may  be  reduced  in  the  MOC 
due  to  automated  processing  and  conversion  of  information.  MH-53E  helicopter 
manning  will  remain  unchanged  for  this  proposed  architecture  since  the  AMCM 
C'*!  Information  system  will  run  in  the  background  with  no  additional  manual 
effort  required. 
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8.  Security 

Security  must  be  transparent  to  the  end  user  and  not  impact  the  speed  at 
which  information  is  transferred.  Data  rates  up  to  1.544  Mbps  (T1  capacity)  are 
possible  using  KG-84C  compatible  link-encryption  devices  over  the  radio-based 
WAN.  The  data  should  also  be  secure  within  the  MOC  LAN  portion  of  the 
AMCM  tactical  network  itself.  This  can  easily  be  performed  by  using  one  of 
several  secure  e-mail  programs  available  today  to  provide  information  confiden¬ 
tiality  and  authentication  inside  a  physically  secure  LAN. 

9.  Available  Technology 

Commercial-off-the-shelf  (COTS)  and  non-development-item  (NDI) 
components  are  available  today  that  support  near-real  time  transmission  of  video, 
imagery  and  text  over  IP  compatible  LANs  and  radio-based  WANs.  However, 
modifications  are  required  to  the  existing  AN/AQS-14A  sonar  interface  as  the 
current  system  has  no  interface  capable  of  transferring  sonar  video  information  to 
the  MH-53E  AMCM  0^1  network  itself  Several  interface  options  have  been 
proposed  by  the  manufacturer. 

CAD  can  be  made  available  for  use  on  the  aircraft  if  desired.  An  Ethernet 
interface  card  can  be  installed  into  an  empty  VME  slot  in  the  CAD  Post-Mission 
Analysis  (PMA)  Workstation  to  interface  with  the  network  on  the  MH-53E  LAN- 

The  PMA  VME-bus-based  cards  would  also  need  to  be  packaged  for 
airborne  use.  Finally  the  Mission  Planning  Station  can  be  attached  to  the  MOC 
network  simply  by  installing  an  Ethernet  network  interface  card  (NIC). 

10.  Cost 

The  marginal  cost  to  achieve  near-real  time  AMCM  command  and  control 
is  minimal,  considering  that  most  of  the  assets  are  already  in  place.  LANs 
(optionally  palletized)  must  be  installed  in  the  MOC  and  MH-53E  helicopters. 


51 


However  these  systems  can  be  built  in  phases  as  components  evolve  and  are  added 
to  the  network.  Communications  equipment  may  also  be  added  incrementally  as 
desired.  The  transmission  of  sonar  video  and  the  use  of  CAD  on  board  the  MH- 
53E  are  not  stated  requirements.  If  CAD  is  not  used  on  the  aircraft  and  video  is 
not  transferred  over  LOS  using  a  UHF  channel,  the  most  significant  costs  in  the 
palletizable  system  will  be  the  Ethernet  interface  to  the  AN/AQS-14A  and  a  HF 
radio/modem.  Thus  all  component/software  costs  are  minimal. 

Where  initial  high  component  costs  can  potentially  become  involved  is  if 
CAD  is  used  to  process  sonar  video  locally  on  the  MH-53E,  or  if  UHF  equipment 
is  used  to  transmit  the  sonar  video  in  order  for  the  video  to  be  remotely  processed 
by  either  manual  operators  or  CAD  in  the  MOC.  These  are  options  which  can  be 
added  to  enhance  the  processing  of  the  sonar  video  information  in  near-real  time. 

In  any  case,  the  sonar  video  has  always  been  "processed"  in  real  time  by  the 
sonar  operators  on  board  the  MH-53E.  The  sonar  operators  currently  review  the 
sonar  tape  in  real  time  and  "mark"  mine-like  contacts  as  they  appear  on  the  screen. 
The  entire  sonar  video  is  also  stored  on  magnetic  tapes  which  may  be  reviewed  by 
manual  operators  upon  the  helicopters  return.  With  the  addition  of  the  tactical 
network,  the  system  may  be  configured  so  that  the  operator  may  select  mine-like 
contacts  and  forward  position,  imagery  and  even  sonar  video  information  over 
either  a  HF,  UHF  or  even  SATCOM  channel;  in  otherwords,  (because  it’s  a  true 
internet),  over  any  and  all  of  the  above.  For  example,  routers  are  capable  of 
sending  3  packets  of  data  to  the  HF  queue,  8  packets  to  the  UHF  queue  and  5 
packets  to  the  Satcom  queue  -  all  of  which  are  part  of  the  same  e-mail  message. 
The  end  system  TCPs  are  perfectly  capable  of  reassembling  the  packets  back 
together  to  form  the  same  original  single  e-mail  message. 
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11.  Options 

Although  near-real  time  video  processing  by  any  other  method  than  the 
operator  on  board  the  helicopter  is  not  required,  the  merits  and  deficiencies  of  the 
options  available  are  worthy  of  further  discussion. 

There  are  three  options  available  to  process  the  sonar  video  in  near-real 
time.  The  first  option  is  to  use  CAD  locally  on  the  MH-53E.  With  CAD  installed 
on  the  aircraft,  the  operational  range  in  which  information  from  CAD  will  be 
available  is  greatly  improved  as  near-real  time  sonar  video  processing  capability 
will  no  longer  limited  to  operations  within  LOS.  The  relevant  mine-like  contact 
information  extracted  from  the  processed  video  can  be  filtered  into  sizes  accept¬ 
able  for  HF  or  Satcom  transmissions  world-wide.  The  only  way  to  process  the 
necessary  information  on  the  aircraft  with  the  same  level  of  "scan"  as  in  the  MOC 
is  to  embed  CAD  into  the  aircraft  system.  This  way  you  still  get  one  operator  and 
one  automated  "look."  This  is  possible  as  the  Post-Mission  Analysis  Station 
computer-aided  detection  algorithm  can  be  added  to  the  LAN  in  the  MH-53E  by 
installing  an  Ethernet  interface  card  in  one  of  the  empty  VME  slots  in  the  PMA 
Station.  Other  options  include  installing  the  algorithm  in  a  different  processor 
either  by  using  the  existing  VME  cards  or  by  porting  the  software  to  a  separate 
host,  such  as  a  VME  based  TAC-4  processor.  The  sonar  video  tape  will  still 
available  for  review  upon  aircraft  return,  or  even  while  in  transit  as  it  is  possible  to 
send  some  information  ahead. 

The  second  option  is  to  process  the  sonar  video  remotely  in  the  MOC.  To 
be  able  to  process  sonar  video  in  near-real  time  in  the  MOC,  additional  UHF 
communications  equipment  is  required  on  the  helicopter  and  in  the  MOC,  as  the 
UHF  transceiver  that  must  be  used  to  provide  the  data  channel  will  be  fully  tasked 
and  unavailable  for  voice  communications.  Therefore  an  existing  voice  radio 
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cannot  be  substituted  or  borrowed  for  the  data  channel  communications.  However 
use  of  UHF  to  transmit  the  sonar  video  so  that  CAD  or  manual  operators  located  in 
the  MOC  can  be  used  to  process  the  sonar  video  in  near-real  time  ultimately  limits 
the  real-time  capability  to  LOS  operations  only.  Additional  problems  arise  when 
numerous  mine-hunting  operations  are  simultaneously  trying  to  transfer  sonar 
video  information  to  the  MOC.  This  requires  additional  hardware  and  personnel 
resources  to  manage  the  additional  volume  of  information. 

The  third  option  is  to  continue  doing  what  is  being  done  now,  with  the 
exception  that  when  spotted  by  sonar  operator,  the  mine-like  object’s  imagery  and 
position  location  information  can  now  be  forwarded  to  the  MOC  via  the  tactical 
internet  using  standard  HF  communications  equipment.  As  before,  this  option 
relies  completely  on  the  sonar  operator  on  board  the  helicopter  to  manually  pick 
out  minelike  image  from  the  sonar  video  and  send  mine-like  object  images  OTH 
using  the  HF  path.  CAD  may  still  be  used  to  process  the  entire  sonar  video  tape 
upon  return  of  the  aircraft  to  the  MOC.  The  end  result  of  this  option  is  that  the 
tape  will  only  be  processed  in  real-time  by  the  sonar  operator,  who  will  not  be 
supported  by  CADs  automatic  detection  algorithms. 

H.  SELECTION  OF  SONAR  VIDEO  PROCESSING  METHOD 

Of  the  three  options,  the  eventual  installation  of  CAD  on  board  the  MH-53E 
is  the  best  choice  for  several  reasons. 

First  it  provides  a  consistent  baseline  for  target  detection.  Operator  training 
and  experience  varies  widely  in  the  fleet.  This  has  previously  led  to  a  high  level  of 
false  AN/AQS-14  contacts  being  reported.  Over  time,  a  lack  of  trust  from  the 
"marking"  of  too  many  false  "mine-like"  objects  led  to  the  development  of 
standard  operating  procedures  which  required  the  tactics  officer  to  review  each 
mine-like  object  and  approve  its  "quality"  prior  to  release  to  the  MIW  community 
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as  a  mine-like  contact.  Policies  such  as  these  have  added  considerable  delay  to  the 
system.  A  new  CAD  software  version  has  reeently  been  developed  and  released 
by  the  manufacturer  which  has  a  very  high  level  of  probability  of  detection. 
Therefore,  CAD  can  be  used  as  an  onboard  tool.  It  will  assist  the  operator  by 
highlighting  potential  targets  as  they  appear  on  the  sonar  operator’s  screen. 
However,  the  operator  still  can  have  the  final  say  on  whether  or  not  the  contact  is 
"marked." 

Second,  CAD  on  board  the  MH-53E  provides  the  highest  level  of  process¬ 
ing  without  requiring  the  addition  of  personnel  or  equipment  to  the  MOC.  In  fact, 
the  level  of  observation  in  the  MH-53E  with  CAD  on  board  may  in  some  cases  be 
better  than  in  the  MOC  as  the  sonar  operator  in  the  aireraft  is  able  to  focus  only  on 
that  one  mission,  while  MOC  sonar  operators  may  be  tasked  with  several  missions 
simultaneously  if  multiple  video  signals  are  being  received  and  if  the  CAD  Post- 
Mission  Analysis  Workstation  is  already  being  used. 

Thirdly,  CAD  in  the  aircraft  helps  to  eliminate  potential  data-fiision 
problems  due  to  information  overload  in  the  MOC,  by  eliminating  the  desire  to 
send  video  at  all.  CAD  in  the  aireraft  will  eventually  diffuse  the  pereeived  video 
requirement  once  near-real  time  TARLOC  position  reports  of  mine-like  objects 
marked  and  forwarded  from  the  aircraft  are  shown  to  be  accurate,  without  any 
assistance  fi'om  the  ground. 

Fourthly,  CAD  in  the  aircraft  reduces  crew  workload  both  in  the  aircraft 
and  in  the  MOC  as  the  data  will  be  fully  filtered  and  processed  at  the  source.  This 
ean  lead  to  less  manning  and  considerable  lifecycle  savings  in  the  MOC  in  both 
equipment  and  material.  Although  CAD  doesn’t  directly  provide  longer  range  of 
operations,  it  helps  reduce  the  data  flows  to  levels  which  can  be  met  by  HF  and 
UHF  SATCOM  throughputs.  Therefore  CAD  processed  information  can  be  sent 
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over  longer  ranges  that  are  only  available  using  narrow  bandwidths  such  as  HF  and 
SATCOM. 

Finally,  CAD  costs  may  be  significantly  reduced  as  the  Remote  Mine- 
Hunting  System  (RMS)  system  contract  has  recently  been  awarded  to  Lockheed 
Martin.  The  RMS  system  will  use  the  same  AN/AQS-14A  sonar  (with  an 
improved  CAD  system)  as  the  AMCM  community.  It  is  possible  to  build  the 
AMCM  internetworked  system  now  in  the  aircraft  without  CAD.  CAD  can  be 
added  later  on,  most  likely  with  less  cost.  In  the  interim,  the  system  will  then  be 
the  same  as  that  presented  in  option  three,  using  only  the  operator  to  scan  the  sonar 
video.  However,  based  on  the  author’s  experience  as  a  squadron  tactics  officer, 
this  is  the  best  path  since  the  real  purpose  of  AMCM  surveillance  and  fast  recon¬ 
naissance  mine-hunting  missions  is  to  provide  a  near-real  time  mine  avoidance 
capability.  The  mission  is  to  see  if  there  are  mine-like  objects  in  the  area;  not  to 
find  every  mine-like  object  in  the  area,  and  the  AMCM  sonar  operator  has  consis¬ 
tently  proven  the  capability  to  do  that. 

I.  SUMMARY 

The  real  requirement  is  to  provide  a  near-real  time  mine  avoidance  cap¬ 
ability  to  the  fleet.  This  can  effectively  be  done  OTH  by  sending  position  mine¬ 
like  object  location  and  single  firame  sonar  imagery  information  processed  in  near- 
real  time  on  board  the  AMCM  MH-53E  assets. 
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VII.  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  discusses  related  work.  Plans,  publications,  programs, 
scheduled  future  demonstrations,  as  well  as  results  from  the  Gulf  of  Mexico 
Exercise  ‘94  (GOMEX)  prototype  system,  are  presented  to  provide  an  overview  of 
the  current  AMCM  O'*!  situation. 

B.  PLANS  AND  PUBLICATIONS 

The  following  publications  officially  address  C^'I  for  the  Mine  Warfare 
community: 


Mine  Warfare  (MIW)  C^I  Master  Plan  [Ref  13:para  3.9.3] 

•  Mine  Warfare  (MIW)  C^'ISR  Operational  Architecture  [Ref  14] 

•  Mine  Warfare  (MIW)  C^ISR  Systems  Architecture  [Ref  15] 

•  C'^I  Architecture  Currently  Supporting  the  Mine  Warfare  Community 
[Ref  12:p.  2] 

•  MIW  C^I  Requirements  Document  (COMINEWARCOM,  1  June, 

1995) 

1.  Mine  Warfare  (MIW)  C^I  Master  Plan 
The  following  is  quoted  from  the  Executive  Summary  of  the  MIW  C'*! 
Master  Plan. 

The  MIW  C‘‘I  Master  Plan  (MIWCMP)  is  one  of  a  series  of  plans  in 
development  at  the  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR)  designed  to  implement  the  Navy's  portion  of  the  JCS  C'^I 
for  the  Warrior  concepts  through  the  objectives  and  vision  of 
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Copernicus. ..Forward....  The  bottom  line  is  that  the  SPAWAR  MIW 
O'*!  Master  Plan  is  designed  to  assist  CNO,  SPAWAR,  PEO 
MINEWAR,  and  other  SYSCOMS  to  provide  Mine  Warfare  with  the 
O'*!  tools  necessary  to  meet  current  and  emerging  challenges... 


However,  it  must  be  understood  throughout  the  MIW  community  that 
"Mine  Warfare"  in  the  SPAWAR  context  is  principally  focused  on  Mine  Warfare 
Ships.  AMCM  requirements  and  systems  integration  aspects  are  presented,  but 
they  in  no  way  drive  the  architecture,  requirements  or  systems  integration  plans  for 
the  overall  MIW  community.  The  "MIW  community"  in  SPAWARs  MIW  O'*! 
Master  Plan  lacks  integration  and  balance. 


The  SPAWAR  MIWCMP  is  designed  to  document  the  strategies, 
plans  and  programs  involving  Command  Control  Communications 
Computer  and  Intelligence  (Cl)  capabilities  for  the  Mine  Warfare 
Ships  currently  under  CNO  and  SPAWAR  sponsorship. 

This  is  evident  as  the  MCS,  MCM,  and  MHC  are  all  strongly  represented 
on  the  Systems  Installation  Planning  Schedule,  and  no  installations  are  planned 
between  FY  97  and  FY04,  (the  entire  range  of  the  chart)  for  all  non-SMCM  assets 
listed  under  MICFAC,  MAST,  EODC^I,  SEAL  C'^I,  and  Airborne  C'’!  in  the 
Deployable  Communications  category. 

The  SPAWAR  MIW  0*1  Master  Plan  is  extensive  and  provides  a  great  level 
of  detail  for  the  SMCM  community.  However,  as  it  clearly  states,  its  primary 
focus  is  on  surface  based  MCM  assets.  The  entire  AMCM  section  from  the  MIW 
Cl  Master  Plan  is  included  below: 


All  military  aircraft  are  presently  equipped  with  HF,  UHF  and/or 
VHF  secure  and/or  non-secure  voice  systems.  Present  systems 
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should  be  used  to  fulfill  all  voice  reporting  requirements.  No 
decision  has  been  made  to  date  on  whether  one  of  the  existing 
Tactical  Data  Link  circuits  should  be  used  to  pass  near-real  time 
acoustical  data,  or  if  a  new  MIW  unique  system  should  be 
developed.  As  an  interim  measure  a  Link- 1 1  type  system 
(compatible  with  the  MICFAC  and  MCS-12)  could  be  deployed  on 
the  MH-53E  AMCM  aircraft.  This  interim  system  should  be 
configured  in  such  a  way  as  to  be  deployed  on  a  pallet  until  a 
permanent  solution  is  identified. 


AMCM  is  only  specifically  addressed  in  two  other  instances  in  the  MIW 
Cl  Master  Plan.  First,  the  SPAWAR  MIW  C'^I  Master  Plan  states  that  there  is  no 
AMCM  plan. 


Though  a  requirement  exists  for  a  Tactical  Data  Link  to  pass  data 
from  the  MH-53  to  the  MCS,  there  has  been  no  resolution  as  to 
whether  one  of  the  existing  link  architectures  will  be  used,  or  if  a 
new  concept  is  to  be  developed  for  Mine  Warfare. 


Second,  MAST  is  "selected"  to  support  AMCM  even  though  it’s 
procurement  and/or  installation  hasn’t  been  planned.  "MAST  has  been  selected  to 
provide  deployable  C'*!  for  the  AMCM  commander."  [Ref  13:para  3.9.3] 

2.  Mine  Warfare  (MIW)  Command  Control  Communication 
Computer  and  Intelligence  Surveillance  and  Reconnaissance 
(C'^ISR)  Operational  Architecture 

The  MIW  C^ISR  Operational  Architecture  is  also  part  of  the  series  of 
documents  from  Space  and  Naval  Warfare  Systems  Command  (SPAWAR).  The 
MIW  C4ISR  Operational  Architecture  proclaims  that  is  a 


standards-based  blueprint  that  will  serve  as  the  official  source 
document  containing  the  operational  requirements,  nodal 
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descriptions,  operational  activities  (or  tasks),  and  information 
exchange  requirement  (lER)  information  for  MIW. 

This  document  identifies  an  overall  MIW  operational  hierarchy.  It  defines  the 
scope  of  the  C^I  architectural  problem  in  terms  of  operational  command 
relationships,  operational  information  exchange  requirements  and  MIW  nodal 
connectivity.  The  Mission  Need  Statement  for  Mine  Warfare  C^^I  System  is 
provided  in  Appendix  E.  AMCM  operational  background  information  is  provided 
in  section  3.3 .2.4.  It  is  important  to  note  that  the  Operational  Information 
Exchange  requirements  listed  in  (Figure  7.1)  C'^ISR  Operational  Architecture) 
cannot  be  supported  with  the  equipment  listed  for  the  MH-53E  in  MIW  Node 
Connectivity  -  Communications  Systems  diagram  as  shown  in  Figure  7.2  C'^ISR 
Systems  Architecture). 

3.  Mine  Warfare  (MIW)  C‘*ISR  Systems  Architecture 
The  MIW  C'‘ISR  Systems  Architecture  is  also  part  of  the  series  of 
documents  from  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR). 
This  document  presents  and  provides  the  Mine  Warfare  MIW  C^I  Systems 
Architecture  as  a  roadmap  and  a  subset  of  the  Naval  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance 
(CISR)  Architecture  which  can  support  MIW,  Joint,  Allied,  and  Coalition  forces, 
and  support  force  interoperability  and  battlespace  dominance.  The  MIW  C'^I 
Systems  Architecture,  when  implemented  will  satisfy  the  operational  activities, 
lERs,  operational  nodal  connectivity  identified  in  the  MIW  C'*!  Operational 
Architecture,  and  provide  top-level  performance  boundaries.  [Ref  15] 
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Figure  7.1.  Operational  Information  Exchange 


61 


T  =  TRANSMIT  ONLY 

EQ  =  EQUIVALENT  CAPABILITY 

LWN  =  LITTORAL  WARFARE  NETWORK 


Figure  7.2.  MIW  Node  Connectivity  -  Communications  Systems 


62 


CMWC  1 ^ 

'MCM  TAd 

GCCS 

_ _CMDR^ 

Active  MCM 


•  =  EXISTING /PLANNED 

Q  = NEEDED 
JMS  =JMCIS/GCCS  MIW  SEGMENT: 


Figure  7.3.  MIW  Node  Connectivity  -  Processing  Systems 
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This  document  provides  a  high  level  overview  of  MIW  Cl  mission  require¬ 
ments  and  interoperability  issues.  Figures  7.2  through  7.3  provide  insight  to  what 
is  planned  for  AMCM.  No  specific  AMCM  System  Architecture  is  provided.  The 
MIW  Node  Connectivity  -  Communication  Systems  diagram,  (Figure  7.2),  reveals 
that  terminal  teletype  (TTY)  and  secure  voice  (SVOX)  are  the  only  existing/ 
planned  AMCM  communication  system  requirements  needed  to  support  the 
AMCM  functions  required  in  the  conduct  of  MIW.  Also,  the  document  is  not 
complete  as  the  MOC  Van,  required  when  the  AMCM  unit  is  not  on  MCS-12,  is 
not  included  in  the  MIW  Node  Connectivity  -  Communications  Systems  diagram 
(Figure  7.2). 

4.  C'*!  Architecture  Currently  Supporting  the  Mine  Warfare 

Community  [Ref.  16] 

This  was  prepared  by  LANTFLT  Systems  Engineering  in  March  ‘96 
following  a  four-day  review  of  the  C^I  architecture  currently  in  use  within  the 
Mine  Warfare  community.  "The  objective  was  to  determine  the  as-is  C'*! 
architecture  and  data  flow  requirements  of  units  involved  in  Mine  Warfare."  [Ref 
16:p.  2]  Shipboard  and  CMWC  based  hardware/software  systems  were  examined 
as  well  as  issues  concerning  upgrading  MIW  nodal  capabilities.  A  list  of  C^I  data 
requirements  are  also  presented.  The  data  requirements  are  broken  down  into 
continuously  supplied  data  and  periodic  supplied  data  categories.  The  contin¬ 
uously  supplied  data  can  be  further  broken  into  intrinsie  "raw"  data  and  derived 
"calculated"  data.  This  document  provides  no  guidance  on  specific  AMCM 
systems  as  they  were  not  examined.  Finally,  the  SPA  WAR  series  of  documents 
listed  in  the  proceeding  paragraphs  were  based  on  the  information  contained  in 
this  document. 
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5.  MIW  C"*!  Requirements  Document  [Ref.  12] 

COMINEWARCOM’s  MIW  Requirements  Document  identifies  the 
fundamental  requirements  for  a  "tactically  effective  MIW  C*!  system."  It  states 
that  a  "MIW  Cl  system  is  to  be  a  segment  within  the  Joint  Maritime  Command 
Information  System  (JMCIS)  to  provide  interoperability  with  Navy,  Joint,  and 
Combined  C*!  systems  and  therefore  will  comply  with  USN  Copernicus  architec¬ 
ture  requirements."  Data  transmission  requirements  listed  include  both  beyond 
line  of  sight  (BLOS)  and  within  line  of  sight  communications.  Continual  as  well 
as  periodic  transmissions  are  also  required.  The  document  also  states  that  "as  a 
minimum,  a  data  link  will  provide  the  following:" 

1 .  MCM  asset  position 

2.  Parameters  to  compute  trailback  and  offset  of  MCM  gear. 

3.  MCM  equipment  settings/performance  data,  when  sweeping. 

4.  Sensor  video  and/or  digital  sonar  image  data,  when  hunting 
(primarily  for  unmaimed  systems).  [Ref  12] 

The  data  flow  requirement  descriptions  contained  within  this  document  are 
extremely  valuable  in  determining  the  required  data  flows  between  MIW  assets. 

C.  PROGRAMS 

1.  The  AN/AQS-20  Data  Link 

The  AN/AQS-20  Data  Link  currently  under  development  by  Raytheon.  It  is 
a  point-to-point,  UHF  line-of-sight  data  link  with  a  throughput  of  250  Kbps.  The 
system  is  based  on  the  1553  data  bus  and  the  Navy  Communications  System 
(NCS)  "glass  cockpit  upgrade."  The  system  will  add  a  third  AN/ARC-210  UHF 
radio,  a  SSE  DSM-102  Satellite  Modem  to  the  aircraft,  and  a  DVME-739  serial 
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communications  controller  card  to  the  AN/AQS-20  console  processor  module  D. 
The  simplex  (send-only)  system  will  supply  unencrypted  AN/AQS-20  sonar  video 
only  within  LOS  ranges  to  the  MOC.  Currently,  only  R&D  has  been  funded  for  a 
prototype  system.  The  AN/AQS-20  sonar  and  data  link  is  scheduled  to  reach  the 
fleet  in  2003. 

The  AN/ARC-210  and  the  SSE  DSM-102  were  utilized  in  the  AMCM  C^I 
Information  System  proof-of-concept  demonstration  as  part  of  the  radio-based 
WAN.  This  was  intentionally  done  to  demonstrate  how  to  convert  this  system  to  a 
secure,  network-compatible  system  that  can  be  used  for  all  missions  not  just  the 
AN/AQS-20  mine-hunting  mission. 

2.  MAST 

Mobile  Ashore  Support  Terminal  (MAST)  is  a  self  contained,  transportable 
C'*!  system  which  can  be  rapidly  deployed  to  meet  any  contingency.  MAST 
provides  an  initial  Cl  capability  for  a  naval  detachment  operating  ashore.  The 
MAST  capabilities  include  a  comprehensive  communications  suite:  HF/UHF/ 
VHP,  SATCOM  and  associated  crypto  gear;  a  C2I  capability:  JMCIS/GCCS,  GPS 
and  an  integrated  briefing  system.  [Ref.  13:para  3.9.3]  According  to  SPAWAR's 
MIW  C'*!  Master  Plan,  MAST  has  been  selected  to  provide  deployable  G^I  for  the 
AMCM  Commander.  However,  it  is  unknown  whether  it  has  been  funded  or  if 
funded,  when  it  will  be  made  available  to  the  AMCM  squadron.  MAST  currently 
costs  $1.25  Million  and  is  expected  to  require  1  year  to  deliver.  MAST  does  not 
integrate  the  current  AMCM  G^I  assets  into  a  coherent  system  or  improve  connec¬ 
tivity  with  the  MH-53E. 

3.  Remote  Minehunting  System  (RMS) 

Lockheed  Martin  was  awarded  the  Remote  Minehunting  System  (RMS) 
contract  in  August  '96.  The  RMS  consists  of  a  semi-submersible  diesel  submarine 
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that  tows  the  AN/AQS-14A  side-scan  sonar.  The  submarine  is  unmanned  and  the 
RMS  will  be  controlled  using  a  LOS  UHF  data  link.  The  LOS  data  link  will  also 
provide  sonar  video  data  and  target  location  information.  The  RMS  sonar  system 
is  to  be  based  on  a  VME  bus  with  Ethernet  ports  to  the  sensor  and  to  the  data  link. 
Computer-aided  detection  (CAD)  will  be  added  to  the  system  as  a  future  upgrade 
using  8  additional  VME  cards.  Two  MVME-167  VME  cards  will  provide 
Ethernet  interface  to  connect  the  Ethernet-based  sensors  and  data  link  to  VME  bus. 
One  MVME-167  card  will  act  as  a  sonar  data  interface  and  perform  sonar  data 
routing  fimctions.  The  other  MVME-167  card  will  act  as  the  image  compression 
interface  and  control  and  perform  message  collection  functions.  A  UHF  radio  will 
be  used  to  transmit  the  data  to  the  command  and  control  platform. 

The  sonar  to  be  used  in  the  initial  RMS  version  (AN/AQS-14A)  is  also 
employed  by  the  MH-53E.  The  AN/AQS-14A  sonar  used  in  AMCM  requires  an 
upgrade  inorder  to  gain  Ethernet  access.  However  AN/AQS-14A  upgrades  being 
made  for  the  semi-submersible  RMS  system  can  also  can  be  used  with  AMCM’s 
AN/AQS-14A.  Common  software  engineering,  research  and  development,  and 
logistics  costs  can  be  drastically  reduced  if  these  components  are  used  for  the 
AMCM  upgrades  to  the  AN/AQS-14A.  It  is  essential  that  common  definitions  and 
interfaces  be  identified  early  on  in  order  to  be  interoperable  and  to  take  advantage 
of  this  parallel  effort. 

4.  Link-ll 

Link- 1 1  is  a  two-way  secure,  netted  link  that  exchanges  information  in  the 
TADIL-A  message  format.  Link- 1 1  functions  as  a  primary  data  link  for  surveil¬ 
lance,  combat  weapons  coordination  and  battle  management.  Link- 1 1  configura¬ 
tions  vary  as  it  may  be  used  over  both  HF  and  UHF  radios.  Link- 1 1  maximum 
throughput  is  6  Kbps,  which  will  not  support  video.  Link-1 1  is  not  currently 
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programmed  for  MCMs,  MHCs  or  AMCM  MH-53E.  MCS-12  received  Link- 1 1 
during  the  conversion  process.  The  MOC  has  Link-1 1  installed. 

5.  Link-16 

"Link-16  is  not  currently  programmed  for  MCMs  or—  MHCs  or  MCS-12. 

It  should  be  a  future  requirement  for  MCS-12,  MCMs,  MHCs,  MICFAC,  MAST 
and  the  COMINEWARCOM  (CMWC)  Command  Center."  [Ref  13:para  3.4.2.2] 

Though  Link- 16  is  to  be  the  primary  data  link  for  the  LfSN,  it  is  restricted  to 
LOS.  In  full  ECCM  mode,  it  supplies  only  28.8  Kbps  and  lacks  the  throughput  to 
support  video.  Since  it  is  based  on  Time  Division  Multiple  Access  (TDMA),  less 
time  is  available  to  each  user  as  more  users  are  added.  As  a  result,  because  each 
user  has  less  time  to  transmit/receive  data,  the  throughput  will  degrade  as  the 
number  of  users  on  each  net  is  increased.  It  will  be  expensive  and  will  not  solve 
all  the  problems  that  expectations  will  place  before  it. 

6.  Lmk-22 

NATO  Improved  Link  Eleven  (NILE)/Link-22  is  an  improved  version  of 
Link- 1 1 .  Through  TDMA,  it  will  be  capable  of  multinetting  with  a  gapless  cover¬ 
age  over  300  NM  range  by  combining  HF  with  UHF  line  of  sight  nodes.  The  link 
will  be  based  on  TADIL-  J  series  data  elements  and  messages.  Link-22  is  not 
currently  programmed  for  MCMs,  MHCs  or  MCS-12.  [Ref  13:para  3.9.3] 

MIW  needs  a  "force  coordination"  networked  communications  system.  The 
tactical-conununications-based  e-mail  and  IP  network  proposed  in  this  thesis  will 
meet  this  need.  What  MIW  does  not  need  is  a  "weapons  coordination" 
communications  system  like  Link- 16,  Link- 1 1  and  Link-22.  These  "weapons 
coordination"  systems  are  very  expensive  and  pose  gigantic  systems  integration 
problems. 
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D.  PREVIOUS  DEMONSTRATIONS 


A  previous  AMCM  data  link  system  includes  EDOs  TLTS  prototype  data 
link  that  was  used  during  the  U.S.  Navy  Gulf  of  Mexico  (GOMEX)  Exercise  in 
1994.  This  effort  demonstrated  the  real-time  capability  to  report  aircraft,  towed 
body,  and  mine-like  object  position  information.  The  data  link  was  also  used  to 
transmit  single  frame  sonar  imagery  over  a  HF  radio  system.  Approximately 
seven  minutes  were  required  to  transfer  the  uncompressed  single  frame  mine-like 
sonar  images  during  the  demonstration.  The  system  successfully  demonstrated 
AN/AQS-14  minelike  contact  analysis  capability  in  the  MOC  as  well  as  transmis¬ 
sion  of  data  from  the  MOC  to  COMINEWARCOM  via  Link-1 1. 

E.  FUTURE  DEMONSTRATIONS 

Future  demonstration  efforts  include  the  Joint  Countermine  Advanced 
Concept  Technology  Demonstration  (JCM  ACTD)  97-2  which  includes  a  proposal 
for  a  MH-53E  data  link.  This  system  is  outlined  in  the  Joint  Countermine  (JCM) 
Advanced  Concept  Technical  Demonstration  (ACTD)  Command,  Control, 
Communications,  and  Intelligence  (G^I)  Component  [Ref.  17].  The  JCM  ACTD 
Data  Link  proposes  to  provide  preformatted  position,  contact  and  status  reports 
(compatible  with  the  display  and  database  features  of  JMCIS)  fi-om  the  MH-53E 
helicopter  to  the  AMCM  control  node  and  the  MCM  Tactical  Commander.  The 
software  on  the  DOS-based  INC  includes  communications  channel  access  proto¬ 
cols  and  a  modified  TCP/IP  protocol  for  use  over  radio  networks.  This  software 
will  be  used  on  all  MIW  platforms  in  the  exercise.  A  RS-232  serial  connection 
will  be  used  to  attach  the  TAC-4  to  the  INC.  The  INC  is  attached  to  the 
SINCGARS  radio  via  a  data  interface  device  or  to  a  KG-84C  cryptological  device 
from  which  it  is  connected  to  a  HF  modem  and  existing  AN/ARC- 174  HF  radio. 
The  bandwidth  provided  by  both  systems  will  not  support  video.  The  maximum 
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throughput  of  the  line-of-sight  SINCGARS  system  is  <  9600bps.  The  throughput 
of  the  HF  system  will  be  unpredictable  as  the  unit  does  not  support  ALE  and  uses 
an  mechanical  coupler.  Finally,  the  detailed  interfaces  with  existing  MH-53E 
systems  remain  to  be  determined  according  to  the  May  ‘96  Configurations  and 
Interface  Description  Document. 

F.  SUMMARY 

Although  many  MIW  O'*!  plans,  publications,  programs,  and  proposed 
systems  exist  today,  no  plan  or  system  currently  satisfies  the  overall  requirements 
of  the  AMCM  community.  None  of  these  plans,  publications,  programs  or 
proposals  integrate  existing  AMCM  squadron  assets  including  JMCIS/Mine 
Warfare  Environmental  Decision  Aids  Library  (MEDAL),  Mission  Planning 
Station,  Post-Mission  Analysis  Station,  and  the  MH-53  E  mine  countermeasures 
helicopter  into  a  cohesive  C'*!  system.  [Ref  18]  The  three-part  series  from  Space 
and  Naval  Warfare  Systems  Command  (SPAWAR)  is  based  on  shipboard  MCM 
requirements.  AMCMs  own  requirements  are  not  weighted  equally  in  the  deter¬ 
mination  of  the  overall  technical  architecture. 

Finally,  although  the  plans  and  programs  mentioned  in  this  chapter  do  not 
provide  specific  guidance  for  fully  integrating  AMCM  C'^I  assets  into  a  cohesive 
AMCM  C^*!  Information  System,  these  plans  and  programs  do  provide  a  invalu¬ 
able  target  baseline  which  the  AMCM  C^I  system  can  reference  to  ensure  compati¬ 
bility  with  other  MIW  C*I  (systems  including  MCS,  MCM,  MHC).  This  reference 
baseline  includes  protocols,  standards,  message  formats,  which  shall  be  compatible 
with  the  AMCM  C^I  Information  System.  System  requirements  can  be  deduced 
from  these  documents  but  no  coherent  implementation  plan  exists  to  meet  these 
requirements.  The  architecture  proposed  in  this  thesis  provides  a  contender 
solution  which  can  solve  this  critical  shortfall. 
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VIII.  RECOMMENDATIONS  FOR  FUTURE  WORK 


A.  INTRODUCTION 

The  AMCM  O'*!  Information  System  can  be  built  today  using  a  tactical 
internet  to  provide  connectivity  between  all  AMCM  C^^I  assets.  This  system  will 
provide  a  significant  step  forward  in  command  and  control  for  the  AMCM 
community.  Future  work  is  required  to  ensure  all  the  necessary  projects  currently 
under  development  can  be  migrated  onto  the  tactical  internet  as  desired. 

B.  RECOMMENDATIONS 

Numerous  products  are  already  on-line  to  appear  in  the  AMCM  community. 

1.  Sensors 

The  AN/AQS-20  sonar  will  be  available  in  the  year  2003.  It  is  not  based  on 
a  internetworked  design,  however  the  console  has  a  VME  serial  port  communica¬ 
tions  card  which  can  be  used  for  AMCM  LAN  access.  However  the  other  inter¬ 
face  definitions  such  as  the  data  definitions  must  also  be  met  as  well  to  provide 
interoperability  within  the  tactical  network.  The  present  data  definitions  are  not 
designed  for  JMCIS  or  MEDAL  interoperability. 

The  RMS  semi-submersible  mine-hunting  system  and  the  AMCM  AN/ 
AQS-14A  programs  must  cooperate  to  provide  as  many  commonalities  as  possible. 
This  will  reduce  costs  and  improve  logistics. 

This  is  an  illustration  how  procurements  coming  out  of  two  different 
program  management  offices  can  duplicate  results  in  incompatible  ways.  Nothing 
in  the  acquisition  system  encourages  them  to  work  together. 

2.  Decision  Support 

AMCM’s  Mission  Planning  System  and  the  JMCIS  mine  warfare  segment 
MEDAL  must  become  interoperable.  The  MH-53E  "glass  cockpit"  Navy  Com¬ 
munications  System  (NCS)  is  currently  being  introduced  to  the  fleet  and  will 
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provide  the  MH-53E  with  a  1553B  data  bus.  The  bus  can  be  interfaced  to  the 
tactical  network  on  the  MH-53E  using  a  1553  based  PCMCIA  card.  However,  the 
MPS  data  module  that  is  loaded  into  the  overhead  in  the  cockpit  (which  preloads 
and  then  stores  all  mission  information  trapped  from  the  1553  bus)  is  incompatible 
with  MEDAL/JMCIS.  Position  reports,  minelike  contact  messages  etc.  cannot  be 
passed  between  the  two  systems  without  manual  conversion.  In  effect,  the 
potential  exists  for  two  entirely  separate,  non-interoperable,  tactical  decision  aids 
(TDA)  to  reside  on  the  same  networked  platforms.  MEDAL  will  be  MIW’s 
primary  TDA.  However,  both  can  be  put  onto  the  network  and  be  interoperable 
once  the  message  format  and  data  definition  issues  are  resolved. 

The  era  of  stovepipe  TDA’s  like  MPS  has  passed.  Modem  TDA’s  must  be 
LAN  based,  host  network  management  platforms  and  use  compatible  data  defini¬ 
tions  and  common  operating  environments  like  those  based  on  the  Naval  Warfare 
Tactical  Data  Base  and  JMCIS/MEDAL  etc. 

3.  Radio-Based  WAN 

Efforts  to  install  incorrect  incompatible  solutions  must  be  abandoned. 
Link-1 1,  Link-22  and  Link- 16  will  cost  far  more  and  be  far  less  useful  and 
effective  in  meeting  MIW  needs  than  a  proven,  widely-compatible,  networkable 
yet  inexpensive  COTS  solution  like  Battle  Force  E-mail.^  Open  solutions  which 
are  secure,  easy  to  clone,  integrate,  adopt  and  understand  can  be  implemented 
with  little  eost  or  risk  today.  The  AN/AQS-20  data  link  program  must  become 
more  than  a  one-way,  point-to-point,  unsecure  (unencrypted),  UHF  radio-based 
LOS  stovepipe.  The  AN/ARC-210  UHF  radio  used  by  this  system  can  be  used  to 
provide  a  secure,  network  compatible,  high  data  rate  UHF/SATCOM  channel  (as 
shown  in  the  proof-of-concept  demonstrations  by  this  thesis). 

^B.F.  e-mail  uses  Qualcomm’s  Eudora  IC  based  E-mail  application.  [Ref.  19] 
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4.  Proposals 

Proposals  must  be  made  early  on  before  it  is  too  costly  and  too  late  to  make 
meaningful  changes  to  projects  currently  under  development.  Plarming 
Documents,  Mission  Need  Statements,  Engineering  Change  Proposals  all  will  be 
required  to  make  meaningful  progress  on  the  internetworked  Cl  front. 

There  are  numerous  programs  that  must  be  integrated.  Doing  so  will  ensure 
connectivity  between  the  necessary  O'*!  systems.  Failing  to  do  so  will  ensure 
AMCM  remains  standing  alone  and  in  the  dark.  This  is  evident  as  our  existing 
baseline  consists  of  stand-alone  decision  aids  with  no  coimectivity  to  pass  critical 
information.  The  problem  is  chronic  as  little  or  no  effort  has  been  made  to  provide 
interoperability  between  AMCM  C'^I  assets.  By  insisting  on  the  proper  architec¬ 
ture  early  on  in  the  requirements  part  of  the  procurement  phase,  it  will  be  virtually 
impossible  for  the  contractor  to  develop  anything  but  the  proper  solution. 

Finally,  the  move  from  AX.25  point-to-point  connections  to  a  reliable 
multicast  transport  protocol  should  be  made  as  soon  as  possible.  Like  AX.25, 
NRAD’s  Battle  Force  E-Mail  system  is  only  the  first  step.  Use  it  to  get  a  basic 
internetworked  working  system  as  soon  as  possible,  but  consider  other  alternatives 
that  meet  the  networked  architecture  at  each  opportunity. 

C.  SUMMARY 

The  AMCM  community  needs  to  implement  the  Cl  Information  System 
based  on  the  architecture  outlined  throughout  this  thesis.  With  the  appropriate 
networked  architecture,  the  network  can  be  expanded  as  the  need  arises.  Without 
the  appropriate  architecture,  the  community  will  be  locked  into  another  closed 
stovepipe  system  tied  to  individual  systems  and  components. 
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IX.  DEMONSTRATION  RESULTS 


A.  INTRODUCTION 

Two  laboratory  proof-of-concept  demonstrations  were  successfully 
conducted.  The  first  demonstration  was  presented  to  Captain  Arnold  (AMCM 
PEO)  on  16  September  1996  and  the  second  demonstration  was  presented  to 
Admiral  Williams  (PEO  MIW)  on  8  October  1996. 

B.  DEMONSTRATION  GOALS 

The  demonstration  goal  was  to  provide  a  working  proof-of-concept 
prototype  using  standard  COTS/NDI  equipment,  NRaD’s  Battle  Force  HF  E-mail 
System,  multicast  backbone  (MBone)  video  tools  within  an  open  architecture 
using  standard  protocols  available  today.  [Ref  17]  The  demonstration  was  also 
intended  to  provide  an  overview  of  the  capabilities  inherent  in  the  system’s 
architectural  design.  These  capabilities  include: 

•  Near-real  time  video  and  message  reports  over  LOS  using  UHF 
equipment 

•  Single  frame  imagery  and  message  reports  OTH  using  HF  equipment 

•  Adjustable  throughput,  frame  rate,  and  resolution  of  the  multicast 
backbone  video  tools 

•  Internet  Protocol  (IP)  routing  and  internet  compatible  HF  e-mail 

•  Flexible,  scalable,  reliable,  open  network  architecture 

The  demonstration  was  an  opportunity  to  provide  a  working  systems-based 
solution  to  AMCM’s  G^I  problem. 


75 


C.  DEMONSTRATION  SETUP 


The  demonstration  was  arranged  using  two  LANs  on  two  separate  tables  to 
simulate  the  MOC  and  a  mobile  MH-53E  helicopter  respectively  as  shown  in 
Figure  9. 1 .  Connectivity  between  the  two  LANs  was  only  possible  through  UHF, 
HF  and  a  microwave  bridge  RF  based  links.  The  "MOC"  LAN  was  also  connected 
via  a  standard  10Base2  Ethernet  cable  to  the  Naval  Postgraduate  School’s  network 
backbone  to  demonstrate  connectivity  to  the  Internet.  AN/AQS-14  sonar  input 
was  simulated  using  an  actual  sonar  playback  videotape  provided  by  the  Heli¬ 
copter  Mine  Countermeasures  Squadron  Fifteen. 

D.  DEMONSTRATION  RESULTS 

AN/AQS-14  sonar  video  was  successfully  converted  from  standard  VHS 
video  cassette  format  into  IP  datagrams  and  forwarded  over  a  "MH-53E"  LAN  to 
the  radio-based  wireless  WAN.  It  was  then  transmitted  via  the  radio  based  WAN 
to  the  "MOC"  LAN  and  forwarded  to  a  processor  where  it  was  displayed  on  a 
monitor  as  a  real-time  sonar  video  stream. 

Single  frame  mine-like  object  images  were  captured  using  a  "frame 
grabber"  fi*om  the  sonar  video  data  stream  and  forwarded  over  the  RF  network  to 
the  MOC  LAN  where  they  automatically  appeared  on  the  screen  as  clear  single 
fi-ame  mine-like  object  images. 

NRaD’s  Battle  Force  HF  E-Mail  was  installed  but  a  "clear  to  send  modem 
error"  precluded  fully  successful  e-mail  operations.  The  error  was  internal  to  the 
modem  itself  and  was  not  a  result  of  any  architectural  or  system  design  flaws. 
NRaD’s  Battle  Force  Electronic  mail  HF  e-mail  system  has  been  proven  to  work 
and  has  successfully  been  demonstrated  in  shipboard  environments. 
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Figure  9.1.  MH-53E  Aircraft 
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UHF  throughput  was  demonstrated  at  250  Kbps  and  at  380Kbps  to  show  the 
frame  rate  that  can  be  expected  using  UHF  based  WAN  communications  channels 
for  video  transmissions. 

Messages  were  transferred  over  the  HF  radio’s  internal  data  link  channel  to 
demonstrate  HF  connectivity. 

The  sonar  video  used  in  the  lab  demonstration  was  not  integrated  with 
aircraft  skew,  heading,  altitude,  time  etc.  as  the  sensors  that  provide  these  inputs 
were  not  available.  Figure  9.2  shows  the  lab  testbed  component  diagram. 

E.  SUMMARY 

The  demonstration  design  objectives  were  met  as  sonar  video  and  single 
frame  imagery  information  were  successfully  transferred  in  near-real  time  over  the 
radio  based  WAN.  Nearly  any  communications  component,  regardless  of 
frequency  (VHF,  UHF,  HF  etc.)  can  be  connected  to  a  router,  controlled,  and  be 
used  to  pass  information  over  the  radio-based  WAN.  This  system  was  ready  to  be 
tested  at  sea.  Planned  testing  was  unexpectedly  terminated  when  the  author’s 
orders  were  changed  just  prior  to  graduation. 
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Figure  9.2.  Lab  Testbed  Component  Diagram 
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X.  LESSONS  LEARNED  AND  CONCLUSIONS 


A.  INTRODUCTION 

This  thesis  was  rapidly  written  after  building  the  prototype  system.  As  a 
result  of  building  the  prototype,  numerous  lessons  have  been  learned  first  hand  that 
would  not  have  been  as  deeply  gleaned  from  a  purely  academic  endeavor. 

B.  LESSONS  LEARNED 

Proper  network  interfaces  are  essential.  The  system  must  be  network¬ 
centric  with  common  LAN  interfaces.  Serial  connections  between  components 
severely  limits  flexibility  and  interoperability.  If  the  components  have  common 
network  interfaces,  they  can  be  attached  to  a  network  and  information  can  be 
routed  or  shared  between  the  components. 

Ethernet  (IEEE802.3)  and  Internet  Protocol  (IP)  compatible  products  are 
widespread.  If  a  system  component  doesn’t  provide  the  interface,  chances  are  an 
internal  or  external  adapter  or  card  can  be  purchased  COTS  that  will  provide  the 
appropriate  interface.  For  example,  Ethernet  and  FDDI  cards  are  available  for 
VME  bus  based  systems. 

Use  what  is  available  and  proven  to  work  before  attempting  exotic  capabil¬ 
ities.  AX.25  and  NRaD’s  Battle  Force  HF  E-Mail  system  is  a  good  start.  After 
successfully  integrating  this  system,  begin  to  add  basic  capabilities  such  as  secure 
e-mail  encryption  tools  and  image  compression. 

Battle  Force  TCP  must  be  modified  for  use  in  wireless  environments. 
Numerous  modification  schemes  are  available.  The  problem  is  well  understood, 
having  been  solved  both  by  the  amateur  radio  community  and  by  other  parts  of  the 
Navy  such  as  NRaD.  NRaD’s  Battle  Force  HF  E-Mail  system  uses  the  JNOS 
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Implementation  of  TCP/IP  over  the  AX.25  packet  radio  data  link  layer.  Adequate 
performance  is  possible  today  nevertheless. 

Data  packaging  is  a  very  important  issue.  The  e-mail  enveloping  definition 
is  the  same  independent  of  the  contents  inside.  MIME  is  recommended  as  it  has 
less  overhead,  is  readily  available,  poses  less  development  risk  than  X.400,  and  is 
the  most  compatible. 

Information  systems  architecture  as  outlined  in  Chapters  II,  III  and  IV  needs 
to  be  corporately  established  throughout  the  MW  community.  This  is  not  a 
programmatic  function.  Information  systems  architecture  is  not  a  platform  issue, 
but  rather  a  cross-platform  one.  A  cadre  of  individuals  must  understand  the 
information  systems  architecture  in  order  to  guide  multiple  programs  in  a  coherent 
direction. 

Systems  engineering  is  no  longer  a  "do  it  once  at  program  inception"  affair. 
It  must  be  viewed  as  life-cycle  activity  from  the  overall  systems  perspective.  Such 
an  approach  was  previously  lacking  for  AMCM.  This  thesis  provides  the  founda¬ 
tion  for  an  overall  system  that  can  be  planned  on  a  life-cycle  basis. 

C.  CONCLUSIONS 

The  transmission  of  sonar  video  itself  is  not  a  necessary  requirement.  The 
use  of  CAD  on  the  MH-53E  LAN  will  provide  a  near-real  time  over-the-horizon 
video  processing  capability,  as  the  TARLOC  position  information  and  single 
frame  mine-like  contact  imagery  can  be  supported  within  HF  transmission  para¬ 
meters. 

Common  data  definitions  are  essential.  Common  data  definitions  save 
processing  time  by  eliminating  conversions  and  provide  data  interoperability 
between  end  systems  which  directly  support  rapid  near-real  time  information 
exchanges  between  the  sensor  and  the  decision  maker. 
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A  good  inherent  design  goal  is  to  get  information  put  into  Internet  Protocol 
(IP).  Once  information  is  converted  into  IP  datagrams,  it  can  be  transported  over 
networks  virtually  everywhere. 

D.  SUMMARY 

Numerous  lessons  were  learned  during  the  building  of  the  prototype.  Most 
importantly,  a  network-centric,  systems  based,  open  architectural  approach 
provides  the  highest  levels  of  interoperability,  availability  and  scalability.  Other 
stovepipe  proprietary  solutions  will  continue  to  fail. 
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